2018-10-02 23:38:19 +08:00
|
|
|
// Copyright 2018 Google Inc. All rights reserved.
|
|
|
|
//
|
|
|
|
// 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 android
|
|
|
|
|
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-11 00:35:25 +08:00
|
|
|
import (
|
2020-02-26 21:45:42 +08:00
|
|
|
"fmt"
|
2019-06-04 06:07:03 +08:00
|
|
|
"sort"
|
2020-02-26 21:45:42 +08:00
|
|
|
"strconv"
|
2020-04-28 00:08:37 +08:00
|
|
|
"strings"
|
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-11 00:35:25 +08:00
|
|
|
"sync"
|
2020-04-07 22:25:44 +08:00
|
|
|
|
|
|
|
"github.com/google/blueprint"
|
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-11 00:35:25 +08:00
|
|
|
)
|
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 17:02:45 +08:00
|
|
|
|
2020-03-12 17:37:20 +08:00
|
|
|
const (
|
|
|
|
SdkVersion_Android10 = 29
|
|
|
|
)
|
|
|
|
|
2020-02-13 09:13:25 +08:00
|
|
|
type ApexInfo struct {
|
2020-08-14 02:24:56 +08:00
|
|
|
// Name of the apex variation that this module is mutated into
|
|
|
|
ApexVariationName string
|
2020-02-13 09:13:25 +08:00
|
|
|
|
2020-02-26 21:45:42 +08:00
|
|
|
MinSdkVersion int
|
2020-04-23 01:05:58 +08:00
|
|
|
Updatable bool
|
2020-02-13 09:13:25 +08:00
|
|
|
}
|
|
|
|
|
2020-03-30 22:33:32 +08:00
|
|
|
// Extracted from ApexModule to make it easier to define custom subsets of the
|
|
|
|
// ApexModule interface and improve code navigation within the IDE.
|
|
|
|
type DepIsInSameApex interface {
|
|
|
|
// DepIsInSameApex tests if the other module 'dep' is installed to the same
|
|
|
|
// APEX as this module
|
|
|
|
DepIsInSameApex(ctx BaseModuleContext, dep Module) bool
|
|
|
|
}
|
|
|
|
|
2018-10-02 23:38:19 +08:00
|
|
|
// ApexModule is the interface that a module type is expected to implement if
|
|
|
|
// the module has to be built differently depending on whether the module
|
|
|
|
// is destined for an apex or not (installed to one of the regular partitions).
|
|
|
|
//
|
|
|
|
// Native shared libraries are one such module type; when it is built for an
|
|
|
|
// APEX, it should depend only on stable interfaces such as NDK, stable AIDL,
|
|
|
|
// or C APIs from other APEXs.
|
|
|
|
//
|
|
|
|
// A module implementing this interface will be mutated into multiple
|
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-11 00:35:25 +08:00
|
|
|
// variations by apex.apexMutator if it is directly or indirectly included
|
2018-10-02 23:38:19 +08:00
|
|
|
// in one or more APEXs. Specifically, if a module is included in apex.foo and
|
|
|
|
// apex.bar then three apex variants are created: platform, apex.foo and
|
|
|
|
// apex.bar. The platform variant is for the regular partitions
|
|
|
|
// (e.g., /system or /vendor, etc.) while the other two are for the APEXs,
|
|
|
|
// respectively.
|
|
|
|
type ApexModule interface {
|
|
|
|
Module
|
2020-03-30 22:33:32 +08:00
|
|
|
DepIsInSameApex
|
|
|
|
|
2018-10-02 23:38:19 +08:00
|
|
|
apexModuleBase() *ApexModuleBase
|
|
|
|
|
2020-07-22 14:17:19 +08:00
|
|
|
// Marks that this module should be built for the specified APEX.
|
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-11 00:35:25 +08:00
|
|
|
// Call this before apex.apexMutator is run.
|
2020-07-22 14:17:19 +08:00
|
|
|
BuildForApex(apex 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-12 06:53:12 +08:00
|
|
|
|
2020-02-13 09:13:25 +08:00
|
|
|
// Returns the APEXes that this module will be built for
|
|
|
|
ApexVariations() []ApexInfo
|
2018-10-02 23:38:19 +08:00
|
|
|
|
2020-08-14 02:24:56 +08:00
|
|
|
// Returns the name of APEX variation that this module will be built for.
|
|
|
|
//Empty string is returned when 'IsForPlatform() == true'. Note that a
|
|
|
|
// module can be included in multiple APEXes, in which case, the module
|
|
|
|
// is mutated into multiple modules each of which for an APEX. This method
|
|
|
|
// returns the name of the APEX that a variant module is for.
|
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-11 00:35:25 +08:00
|
|
|
// Call this after apex.apexMutator is run.
|
2020-08-14 02:24:56 +08:00
|
|
|
ApexVariationName() string
|
2018-10-02 23:38:19 +08:00
|
|
|
|
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-11 00:35:25 +08:00
|
|
|
// Tests whether this module will be built for the platform or not.
|
2020-08-14 02:24:56 +08:00
|
|
|
// This is a shortcut for ApexVariationName() == ""
|
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-11 00:35:25 +08:00
|
|
|
IsForPlatform() bool
|
|
|
|
|
|
|
|
// Tests if this module could have APEX variants. APEX variants are
|
2018-10-02 23:38:19 +08:00
|
|
|
// created only for the modules that returns true here. This is useful
|
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-11 00:35:25 +08:00
|
|
|
// for not creating APEX variants for certain types of shared libraries
|
|
|
|
// such as NDK stubs.
|
2018-10-02 23:38:19 +08:00
|
|
|
CanHaveApexVariants() bool
|
|
|
|
|
|
|
|
// Tests if this module can be installed to APEX as a file. For example,
|
|
|
|
// this would return true for shared libs while return false for static
|
|
|
|
// libs.
|
|
|
|
IsInstallableToApex() bool
|
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-11 00:35:25 +08:00
|
|
|
|
|
|
|
// Mutate this module into one or more variants each of which is built
|
2020-07-22 14:17:19 +08:00
|
|
|
// for an APEX marked via BuildForApex().
|
2019-11-19 07:28:57 +08:00
|
|
|
CreateApexVariations(mctx BottomUpMutatorContext) []Module
|
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-11 00:35:25 +08:00
|
|
|
|
Add apex_available to control the availablity of a module to APEXes
apex_available property controls the availability of a module to APEXes.
For example, `apex_available: ["myapex", "otherapex"]` makes the module
available only to the two APEXes: myapex and otherapex, and nothing
else, even to the platform.
If the module is intended to be available to any APEX, then a pseudo
name "//apex_available:anyapex" can be used.
If the module is intended to be available to the platform, then another
pseudo name "//apex_available:platform" is used.
For now, if unspecified, this property defaults to ["//apex_available:platform",
"//apex_available:anyapex"], which means the module is available to everybody.
This will be reduced to ["//apex_available:platform"], when marking for
apex_available for existing modules are finished.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Id4b233c3056c7858f984cbf9427cfac4118b2682
2019-09-30 15:04:35 +08:00
|
|
|
// Tests if this module is available for the specified APEX or ":platform"
|
|
|
|
AvailableFor(what string) bool
|
2019-10-15 14:20:07 +08: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 15:37:39 +08:00
|
|
|
// Return true if this module is not available to platform (i.e. apex_available
|
|
|
|
// property doesn't have "//apex_available:platform"), or shouldn't be available
|
|
|
|
// to platform, which is the case when this module depends on other module that
|
|
|
|
// isn't available to platform.
|
|
|
|
NotAvailableForPlatform() bool
|
|
|
|
|
|
|
|
// Mark that this module is not available to platform. Set by the
|
|
|
|
// check-platform-availability mutator in the apex package.
|
|
|
|
SetNotAvailableForPlatform()
|
|
|
|
|
Enforce apex.min_sdk_version for bundled builds
Previously, when Q-targeting apexes are bundled-built, they are built
against the latest stubs.
It was because unwinder is linked dynamically in R and APIs are provided
by libc while Q apexes should run on Q where libc doesn't provide those
APIs. To make Q apexes run on Q device, libc++ should be linked with
static unwinder. But, because libc++ with static unwinder may cause problem
on HWASAN build, Q apexes were built against the latest stubs for bundled
build.
However, Q apexes should be built against Q stubs.
Now, only for HWASAN builds, Q apexes are built against the latest stubs
(and native modules are not linked with static unwinder).
Bug: 151912436
Test: TARGET_SANITIZE=hwaddress m
=> Q apexes(media, resolv, ..) are linked with the latest stubs
m
=> Q apexes are linked with Q stubs,
and Q apexes' libc++ is linked with static unwinder
Merged-In: If32f1b547e6d93e3955c7521eec8aef5851f908c
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
(cherry picked from commit 7406660685a9a085c433ba7081cc6984f66fa732)
Exempt-From-Owner-Approval: cp from internal
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
2020-03-20 03:29:24 +08:00
|
|
|
// Returns the highest version which is <= maxSdkVersion.
|
|
|
|
// For example, with maxSdkVersion is 10 and versionList is [9,11]
|
|
|
|
// it returns 9 as string
|
|
|
|
ChooseSdkVersion(versionList []string, maxSdkVersion int) (string, error)
|
2020-04-23 01:05:58 +08:00
|
|
|
|
|
|
|
// Tests if the module comes from an updatable APEX.
|
|
|
|
Updatable() bool
|
2020-04-13 15:19:48 +08:00
|
|
|
|
|
|
|
// List of APEXes that this module tests. The module has access to
|
|
|
|
// the private part of the listed APEXes even when it is not included in the
|
|
|
|
// APEXes.
|
|
|
|
TestFor() []string
|
2020-04-15 10:03:39 +08:00
|
|
|
|
|
|
|
// Returns nil if this module supports sdkVersion
|
|
|
|
// Otherwise, returns error with reason
|
|
|
|
ShouldSupportSdkVersion(ctx BaseModuleContext, sdkVersion int) error
|
2018-10-02 23:38:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
type ApexProperties struct {
|
2020-01-17 21:02:56 +08:00
|
|
|
// Availability of this module in APEXes. Only the listed APEXes can contain
|
|
|
|
// this module. If the module has stubs then other APEXes and the platform may
|
|
|
|
// access it through them (subject to visibility).
|
|
|
|
//
|
Add apex_available to control the availablity of a module to APEXes
apex_available property controls the availability of a module to APEXes.
For example, `apex_available: ["myapex", "otherapex"]` makes the module
available only to the two APEXes: myapex and otherapex, and nothing
else, even to the platform.
If the module is intended to be available to any APEX, then a pseudo
name "//apex_available:anyapex" can be used.
If the module is intended to be available to the platform, then another
pseudo name "//apex_available:platform" is used.
For now, if unspecified, this property defaults to ["//apex_available:platform",
"//apex_available:anyapex"], which means the module is available to everybody.
This will be reduced to ["//apex_available:platform"], when marking for
apex_available for existing modules are finished.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Id4b233c3056c7858f984cbf9427cfac4118b2682
2019-09-30 15:04:35 +08:00
|
|
|
// "//apex_available:anyapex" is a pseudo APEX name that matches to any APEX.
|
|
|
|
// "//apex_available:platform" refers to non-APEX partitions like "system.img".
|
2020-07-29 08:37:46 +08:00
|
|
|
// "com.android.gki.*" matches any APEX module name with the prefix "com.android.gki.".
|
2020-02-13 01:30:45 +08:00
|
|
|
// Default is ["//apex_available:platform"].
|
Add apex_available to control the availablity of a module to APEXes
apex_available property controls the availability of a module to APEXes.
For example, `apex_available: ["myapex", "otherapex"]` makes the module
available only to the two APEXes: myapex and otherapex, and nothing
else, even to the platform.
If the module is intended to be available to any APEX, then a pseudo
name "//apex_available:anyapex" can be used.
If the module is intended to be available to the platform, then another
pseudo name "//apex_available:platform" is used.
For now, if unspecified, this property defaults to ["//apex_available:platform",
"//apex_available:anyapex"], which means the module is available to everybody.
This will be reduced to ["//apex_available:platform"], when marking for
apex_available for existing modules are finished.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Id4b233c3056c7858f984cbf9427cfac4118b2682
2019-09-30 15:04:35 +08:00
|
|
|
Apex_available []string
|
|
|
|
|
2020-02-13 09:13:25 +08:00
|
|
|
Info ApexInfo `blueprint:"mutated"`
|
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 15:37:39 +08:00
|
|
|
|
|
|
|
NotAvailableForPlatform bool `blueprint:"mutated"`
|
2018-10-02 23:38:19 +08:00
|
|
|
}
|
|
|
|
|
2020-04-07 22:25:44 +08:00
|
|
|
// Marker interface that identifies dependencies that are excluded from APEX
|
|
|
|
// contents.
|
|
|
|
type ExcludeFromApexContentsTag interface {
|
|
|
|
blueprint.DependencyTag
|
|
|
|
|
|
|
|
// Method that differentiates this interface from others.
|
|
|
|
ExcludeFromApexContents()
|
|
|
|
}
|
|
|
|
|
2018-10-02 23:38:19 +08:00
|
|
|
// Provides default implementation for the ApexModule interface. APEX-aware
|
|
|
|
// modules are expected to include this struct and call InitApexModule().
|
|
|
|
type ApexModuleBase struct {
|
|
|
|
ApexProperties ApexProperties
|
|
|
|
|
|
|
|
canHaveApexVariants bool
|
2019-06-04 06:07:03 +08:00
|
|
|
|
|
|
|
apexVariationsLock sync.Mutex // protects apexVariations during parallel apexDepsMutator
|
2020-02-13 09:13:25 +08:00
|
|
|
apexVariations []ApexInfo
|
2018-10-02 23:38:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
func (m *ApexModuleBase) apexModuleBase() *ApexModuleBase {
|
|
|
|
return m
|
|
|
|
}
|
|
|
|
|
2020-03-04 22:22:45 +08:00
|
|
|
func (m *ApexModuleBase) ApexAvailable() []string {
|
|
|
|
return m.ApexProperties.Apex_available
|
|
|
|
}
|
|
|
|
|
2020-04-13 15:19:48 +08:00
|
|
|
func (m *ApexModuleBase) TestFor() []string {
|
|
|
|
// To be implemented by concrete types inheriting ApexModuleBase
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-07-22 14:17:19 +08:00
|
|
|
func (m *ApexModuleBase) BuildForApex(apex ApexInfo) {
|
2019-06-04 06:07:03 +08:00
|
|
|
m.apexVariationsLock.Lock()
|
|
|
|
defer m.apexVariationsLock.Unlock()
|
2020-07-22 14:17:19 +08:00
|
|
|
for _, v := range m.apexVariations {
|
2020-08-14 02:24:56 +08:00
|
|
|
if v.ApexVariationName == apex.ApexVariationName {
|
2020-07-22 14:17:19 +08:00
|
|
|
return
|
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-12 06:53:12 +08:00
|
|
|
}
|
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-11 00:35:25 +08:00
|
|
|
}
|
2020-07-22 14:17:19 +08:00
|
|
|
m.apexVariations = append(m.apexVariations, apex)
|
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-11 00:35:25 +08:00
|
|
|
}
|
|
|
|
|
2020-02-13 09:13:25 +08:00
|
|
|
func (m *ApexModuleBase) ApexVariations() []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-12 06:53:12 +08:00
|
|
|
return m.apexVariations
|
|
|
|
}
|
|
|
|
|
2020-08-14 02:24:56 +08:00
|
|
|
func (m *ApexModuleBase) ApexVariationName() string {
|
|
|
|
return m.ApexProperties.Info.ApexVariationName
|
2018-10-02 23:38:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
func (m *ApexModuleBase) IsForPlatform() bool {
|
2020-08-14 02:24:56 +08:00
|
|
|
return m.ApexProperties.Info.ApexVariationName == ""
|
2018-10-02 23:38:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
func (m *ApexModuleBase) CanHaveApexVariants() bool {
|
|
|
|
return m.canHaveApexVariants
|
|
|
|
}
|
|
|
|
|
|
|
|
func (m *ApexModuleBase) IsInstallableToApex() bool {
|
|
|
|
// should be overriden if needed
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
Add apex_available to control the availablity of a module to APEXes
apex_available property controls the availability of a module to APEXes.
For example, `apex_available: ["myapex", "otherapex"]` makes the module
available only to the two APEXes: myapex and otherapex, and nothing
else, even to the platform.
If the module is intended to be available to any APEX, then a pseudo
name "//apex_available:anyapex" can be used.
If the module is intended to be available to the platform, then another
pseudo name "//apex_available:platform" is used.
For now, if unspecified, this property defaults to ["//apex_available:platform",
"//apex_available:anyapex"], which means the module is available to everybody.
This will be reduced to ["//apex_available:platform"], when marking for
apex_available for existing modules are finished.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Id4b233c3056c7858f984cbf9427cfac4118b2682
2019-09-30 15:04:35 +08:00
|
|
|
const (
|
2019-12-02 23:43:57 +08:00
|
|
|
AvailableToPlatform = "//apex_available:platform"
|
2020-03-06 20:30:13 +08:00
|
|
|
AvailableToAnyApex = "//apex_available:anyapex"
|
2020-07-29 08:37:46 +08:00
|
|
|
AvailableToGkiApex = "com.android.gki.*"
|
Add apex_available to control the availablity of a module to APEXes
apex_available property controls the availability of a module to APEXes.
For example, `apex_available: ["myapex", "otherapex"]` makes the module
available only to the two APEXes: myapex and otherapex, and nothing
else, even to the platform.
If the module is intended to be available to any APEX, then a pseudo
name "//apex_available:anyapex" can be used.
If the module is intended to be available to the platform, then another
pseudo name "//apex_available:platform" is used.
For now, if unspecified, this property defaults to ["//apex_available:platform",
"//apex_available:anyapex"], which means the module is available to everybody.
This will be reduced to ["//apex_available:platform"], when marking for
apex_available for existing modules are finished.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Id4b233c3056c7858f984cbf9427cfac4118b2682
2019-09-30 15:04:35 +08:00
|
|
|
)
|
|
|
|
|
2019-10-07 14:47:24 +08:00
|
|
|
func CheckAvailableForApex(what string, apex_available []string) bool {
|
|
|
|
if len(apex_available) == 0 {
|
2020-01-10 23:12:39 +08:00
|
|
|
// apex_available defaults to ["//apex_available:platform"],
|
|
|
|
// which means 'available to the platform but no apexes'.
|
|
|
|
return what == AvailableToPlatform
|
Add apex_available to control the availablity of a module to APEXes
apex_available property controls the availability of a module to APEXes.
For example, `apex_available: ["myapex", "otherapex"]` makes the module
available only to the two APEXes: myapex and otherapex, and nothing
else, even to the platform.
If the module is intended to be available to any APEX, then a pseudo
name "//apex_available:anyapex" can be used.
If the module is intended to be available to the platform, then another
pseudo name "//apex_available:platform" is used.
For now, if unspecified, this property defaults to ["//apex_available:platform",
"//apex_available:anyapex"], which means the module is available to everybody.
This will be reduced to ["//apex_available:platform"], when marking for
apex_available for existing modules are finished.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Id4b233c3056c7858f984cbf9427cfac4118b2682
2019-09-30 15:04:35 +08:00
|
|
|
}
|
2019-10-07 14:47:24 +08:00
|
|
|
return InList(what, apex_available) ||
|
2020-07-29 08:37:46 +08:00
|
|
|
(what != AvailableToPlatform && InList(AvailableToAnyApex, apex_available)) ||
|
|
|
|
(strings.HasPrefix(what, "com.android.gki.") && InList(AvailableToGkiApex, apex_available))
|
2019-10-07 14:47:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
func (m *ApexModuleBase) AvailableFor(what string) bool {
|
|
|
|
return CheckAvailableForApex(what, m.ApexProperties.Apex_available)
|
Add apex_available to control the availablity of a module to APEXes
apex_available property controls the availability of a module to APEXes.
For example, `apex_available: ["myapex", "otherapex"]` makes the module
available only to the two APEXes: myapex and otherapex, and nothing
else, even to the platform.
If the module is intended to be available to any APEX, then a pseudo
name "//apex_available:anyapex" can be used.
If the module is intended to be available to the platform, then another
pseudo name "//apex_available:platform" is used.
For now, if unspecified, this property defaults to ["//apex_available:platform",
"//apex_available:anyapex"], which means the module is available to everybody.
This will be reduced to ["//apex_available:platform"], when marking for
apex_available for existing modules are finished.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Id4b233c3056c7858f984cbf9427cfac4118b2682
2019-09-30 15:04:35 +08: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 15:37:39 +08:00
|
|
|
func (m *ApexModuleBase) NotAvailableForPlatform() bool {
|
|
|
|
return m.ApexProperties.NotAvailableForPlatform
|
|
|
|
}
|
|
|
|
|
|
|
|
func (m *ApexModuleBase) SetNotAvailableForPlatform() {
|
|
|
|
m.ApexProperties.NotAvailableForPlatform = true
|
|
|
|
}
|
|
|
|
|
2019-10-15 14:20:07 +08:00
|
|
|
func (m *ApexModuleBase) DepIsInSameApex(ctx BaseModuleContext, dep Module) bool {
|
|
|
|
// By default, if there is a dependency from A to B, we try to include both in the same APEX,
|
|
|
|
// unless B is explicitly from outside of the APEX (i.e. a stubs lib). Thus, returning true.
|
|
|
|
// This is overridden by some module types like apex.ApexBundle, cc.Module, java.Module, etc.
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
Enforce apex.min_sdk_version for bundled builds
Previously, when Q-targeting apexes are bundled-built, they are built
against the latest stubs.
It was because unwinder is linked dynamically in R and APIs are provided
by libc while Q apexes should run on Q where libc doesn't provide those
APIs. To make Q apexes run on Q device, libc++ should be linked with
static unwinder. But, because libc++ with static unwinder may cause problem
on HWASAN build, Q apexes were built against the latest stubs for bundled
build.
However, Q apexes should be built against Q stubs.
Now, only for HWASAN builds, Q apexes are built against the latest stubs
(and native modules are not linked with static unwinder).
Bug: 151912436
Test: TARGET_SANITIZE=hwaddress m
=> Q apexes(media, resolv, ..) are linked with the latest stubs
m
=> Q apexes are linked with Q stubs,
and Q apexes' libc++ is linked with static unwinder
Merged-In: If32f1b547e6d93e3955c7521eec8aef5851f908c
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
(cherry picked from commit 7406660685a9a085c433ba7081cc6984f66fa732)
Exempt-From-Owner-Approval: cp from internal
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
2020-03-20 03:29:24 +08:00
|
|
|
func (m *ApexModuleBase) ChooseSdkVersion(versionList []string, maxSdkVersion int) (string, error) {
|
2020-02-26 21:45:42 +08:00
|
|
|
for i := range versionList {
|
|
|
|
ver, _ := strconv.Atoi(versionList[len(versionList)-i-1])
|
Enforce apex.min_sdk_version for bundled builds
Previously, when Q-targeting apexes are bundled-built, they are built
against the latest stubs.
It was because unwinder is linked dynamically in R and APIs are provided
by libc while Q apexes should run on Q where libc doesn't provide those
APIs. To make Q apexes run on Q device, libc++ should be linked with
static unwinder. But, because libc++ with static unwinder may cause problem
on HWASAN build, Q apexes were built against the latest stubs for bundled
build.
However, Q apexes should be built against Q stubs.
Now, only for HWASAN builds, Q apexes are built against the latest stubs
(and native modules are not linked with static unwinder).
Bug: 151912436
Test: TARGET_SANITIZE=hwaddress m
=> Q apexes(media, resolv, ..) are linked with the latest stubs
m
=> Q apexes are linked with Q stubs,
and Q apexes' libc++ is linked with static unwinder
Merged-In: If32f1b547e6d93e3955c7521eec8aef5851f908c
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
(cherry picked from commit 7406660685a9a085c433ba7081cc6984f66fa732)
Exempt-From-Owner-Approval: cp from internal
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
2020-03-20 03:29:24 +08:00
|
|
|
if ver <= maxSdkVersion {
|
2020-02-26 21:45:42 +08:00
|
|
|
return versionList[len(versionList)-i-1], nil
|
|
|
|
}
|
|
|
|
}
|
Enforce apex.min_sdk_version for bundled builds
Previously, when Q-targeting apexes are bundled-built, they are built
against the latest stubs.
It was because unwinder is linked dynamically in R and APIs are provided
by libc while Q apexes should run on Q where libc doesn't provide those
APIs. To make Q apexes run on Q device, libc++ should be linked with
static unwinder. But, because libc++ with static unwinder may cause problem
on HWASAN build, Q apexes were built against the latest stubs for bundled
build.
However, Q apexes should be built against Q stubs.
Now, only for HWASAN builds, Q apexes are built against the latest stubs
(and native modules are not linked with static unwinder).
Bug: 151912436
Test: TARGET_SANITIZE=hwaddress m
=> Q apexes(media, resolv, ..) are linked with the latest stubs
m
=> Q apexes are linked with Q stubs,
and Q apexes' libc++ is linked with static unwinder
Merged-In: If32f1b547e6d93e3955c7521eec8aef5851f908c
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
(cherry picked from commit 7406660685a9a085c433ba7081cc6984f66fa732)
Exempt-From-Owner-Approval: cp from internal
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
2020-03-20 03:29:24 +08:00
|
|
|
return "", fmt.Errorf("not found a version(<=%d) in versionList: %v", maxSdkVersion, versionList)
|
2020-02-26 21:45:42 +08:00
|
|
|
}
|
|
|
|
|
Add apex_available to control the availablity of a module to APEXes
apex_available property controls the availability of a module to APEXes.
For example, `apex_available: ["myapex", "otherapex"]` makes the module
available only to the two APEXes: myapex and otherapex, and nothing
else, even to the platform.
If the module is intended to be available to any APEX, then a pseudo
name "//apex_available:anyapex" can be used.
If the module is intended to be available to the platform, then another
pseudo name "//apex_available:platform" is used.
For now, if unspecified, this property defaults to ["//apex_available:platform",
"//apex_available:anyapex"], which means the module is available to everybody.
This will be reduced to ["//apex_available:platform"], when marking for
apex_available for existing modules are finished.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Id4b233c3056c7858f984cbf9427cfac4118b2682
2019-09-30 15:04:35 +08:00
|
|
|
func (m *ApexModuleBase) checkApexAvailableProperty(mctx BaseModuleContext) {
|
|
|
|
for _, n := range m.ApexProperties.Apex_available {
|
2020-07-29 08:37:46 +08:00
|
|
|
if n == AvailableToPlatform || n == AvailableToAnyApex || n == AvailableToGkiApex {
|
Add apex_available to control the availablity of a module to APEXes
apex_available property controls the availability of a module to APEXes.
For example, `apex_available: ["myapex", "otherapex"]` makes the module
available only to the two APEXes: myapex and otherapex, and nothing
else, even to the platform.
If the module is intended to be available to any APEX, then a pseudo
name "//apex_available:anyapex" can be used.
If the module is intended to be available to the platform, then another
pseudo name "//apex_available:platform" is used.
For now, if unspecified, this property defaults to ["//apex_available:platform",
"//apex_available:anyapex"], which means the module is available to everybody.
This will be reduced to ["//apex_available:platform"], when marking for
apex_available for existing modules are finished.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Id4b233c3056c7858f984cbf9427cfac4118b2682
2019-09-30 15:04:35 +08:00
|
|
|
continue
|
|
|
|
}
|
2019-10-08 17:40:51 +08:00
|
|
|
if !mctx.OtherModuleExists(n) && !mctx.Config().AllowMissingDependencies() {
|
Add apex_available to control the availablity of a module to APEXes
apex_available property controls the availability of a module to APEXes.
For example, `apex_available: ["myapex", "otherapex"]` makes the module
available only to the two APEXes: myapex and otherapex, and nothing
else, even to the platform.
If the module is intended to be available to any APEX, then a pseudo
name "//apex_available:anyapex" can be used.
If the module is intended to be available to the platform, then another
pseudo name "//apex_available:platform" is used.
For now, if unspecified, this property defaults to ["//apex_available:platform",
"//apex_available:anyapex"], which means the module is available to everybody.
This will be reduced to ["//apex_available:platform"], when marking for
apex_available for existing modules are finished.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Id4b233c3056c7858f984cbf9427cfac4118b2682
2019-09-30 15:04:35 +08:00
|
|
|
mctx.PropertyErrorf("apex_available", "%q is not a valid module name", n)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-23 01:05:58 +08:00
|
|
|
func (m *ApexModuleBase) Updatable() bool {
|
|
|
|
return m.ApexProperties.Info.Updatable
|
|
|
|
}
|
|
|
|
|
2020-02-13 09:13:25 +08:00
|
|
|
type byApexName []ApexInfo
|
|
|
|
|
|
|
|
func (a byApexName) Len() int { return len(a) }
|
|
|
|
func (a byApexName) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
|
2020-08-14 02:24:56 +08:00
|
|
|
func (a byApexName) Less(i, j int) bool { return a[i].ApexVariationName < a[j].ApexVariationName }
|
2020-02-13 09:13:25 +08:00
|
|
|
|
2019-11-19 07:28:57 +08:00
|
|
|
func (m *ApexModuleBase) CreateApexVariations(mctx BottomUpMutatorContext) []Module {
|
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-11 00:35:25 +08:00
|
|
|
if len(m.apexVariations) > 0 {
|
Add apex_available to control the availablity of a module to APEXes
apex_available property controls the availability of a module to APEXes.
For example, `apex_available: ["myapex", "otherapex"]` makes the module
available only to the two APEXes: myapex and otherapex, and nothing
else, even to the platform.
If the module is intended to be available to any APEX, then a pseudo
name "//apex_available:anyapex" can be used.
If the module is intended to be available to the platform, then another
pseudo name "//apex_available:platform" is used.
For now, if unspecified, this property defaults to ["//apex_available:platform",
"//apex_available:anyapex"], which means the module is available to everybody.
This will be reduced to ["//apex_available:platform"], when marking for
apex_available for existing modules are finished.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Id4b233c3056c7858f984cbf9427cfac4118b2682
2019-09-30 15:04:35 +08:00
|
|
|
m.checkApexAvailableProperty(mctx)
|
apex_available tracks static dependencies
This change fixes a bug that apex_available is not enforced for static
dependencies. For example, a module with 'apex_available:
["//apex_available:platform"]' was able to be statically linked to any
APEX. This was happening because the check was done on the modules that
are actually installed to an APEX. Static dependencies of the modules
were not counted as they are not installed to the APEX as files.
Fixing this bug by doing the check by traversing the tree in the method
checkApexAvailability.
This change includes a few number of related changes:
1) DepIsInSameApex implementation for cc.Module was changed as well.
Previuosly, it returned false only when the dependency is actually a
stub variant of a lib. Now, it returns false when the dependency has one
or more stub variants. To understand why, we need to recall that when
there is a dependency to a lib having stubs, we actually create two
dependencies: to the non-stub variant and to the stub variant during the
DepsMutator phase. And later in the build action generation phase, we
choose one of them depending on the context. Also recall that an APEX
variant is created only when DepIsInSameApex returns true. Given these,
with the previous implementatin of DepIsInSameApex, we did create apex
variants of the non-stub variant of the dependency, while not creating
the apex variant for the stub variant. This is not right; we needlessly
created the apex variant. The extra apex variant has caused no harm so
far, but since the apex_available check became more correct, it actually
breaks the build. To fix the issue, we stop creating the APEX variant
both for non-stub and stub variants.
2) platform variant is created regardless of the apex_available value.
This is required for the case when a library X that provides stub is in
an APEX A and is configured to be available only for A. In that case,
libs in other APEX can't use the stub library since the stub library is
mutated only for apex A. By creating the platform variant for the stub
library, it can be used from outside as the default dependency variation
is 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-31 01:49:53 +08:00
|
|
|
|
2020-02-13 09:13:25 +08:00
|
|
|
sort.Sort(byApexName(m.apexVariations))
|
Add apex_available to control the availablity of a module to APEXes
apex_available property controls the availability of a module to APEXes.
For example, `apex_available: ["myapex", "otherapex"]` makes the module
available only to the two APEXes: myapex and otherapex, and nothing
else, even to the platform.
If the module is intended to be available to any APEX, then a pseudo
name "//apex_available:anyapex" can be used.
If the module is intended to be available to the platform, then another
pseudo name "//apex_available:platform" is used.
For now, if unspecified, this property defaults to ["//apex_available:platform",
"//apex_available:anyapex"], which means the module is available to everybody.
This will be reduced to ["//apex_available:platform"], when marking for
apex_available for existing modules are finished.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Id4b233c3056c7858f984cbf9427cfac4118b2682
2019-09-30 15:04:35 +08:00
|
|
|
variations := []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-31 01:49:53 +08:00
|
|
|
variations = append(variations, "") // Original variation for platform
|
2020-02-13 09:13:25 +08:00
|
|
|
for _, apex := range m.apexVariations {
|
2020-08-14 02:24:56 +08:00
|
|
|
variations = append(variations, apex.ApexVariationName)
|
2020-02-13 09:13:25 +08:00
|
|
|
}
|
2018-12-26 15:32:21 +08:00
|
|
|
|
2019-12-27 13:11:47 +08:00
|
|
|
defaultVariation := ""
|
|
|
|
mctx.SetDefaultDependencyVariation(&defaultVariation)
|
apex_available tracks static dependencies
This change fixes a bug that apex_available is not enforced for static
dependencies. For example, a module with 'apex_available:
["//apex_available:platform"]' was able to be statically linked to any
APEX. This was happening because the check was done on the modules that
are actually installed to an APEX. Static dependencies of the modules
were not counted as they are not installed to the APEX as files.
Fixing this bug by doing the check by traversing the tree in the method
checkApexAvailability.
This change includes a few number of related changes:
1) DepIsInSameApex implementation for cc.Module was changed as well.
Previuosly, it returned false only when the dependency is actually a
stub variant of a lib. Now, it returns false when the dependency has one
or more stub variants. To understand why, we need to recall that when
there is a dependency to a lib having stubs, we actually create two
dependencies: to the non-stub variant and to the stub variant during the
DepsMutator phase. And later in the build action generation phase, we
choose one of them depending on the context. Also recall that an APEX
variant is created only when DepIsInSameApex returns true. Given these,
with the previous implementatin of DepIsInSameApex, we did create apex
variants of the non-stub variant of the dependency, while not creating
the apex variant for the stub variant. This is not right; we needlessly
created the apex variant. The extra apex variant has caused no harm so
far, but since the apex_available check became more correct, it actually
breaks the build. To fix the issue, we stop creating the APEX variant
both for non-stub and stub variants.
2) platform variant is created regardless of the apex_available value.
This is required for the case when a library X that provides stub is in
an APEX A and is configured to be available only for A. In that case,
libs in other APEX can't use the stub library since the stub library is
mutated only for apex A. By creating the platform variant for the stub
library, it can be used from outside as the default dependency variation
is 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-31 01:49:53 +08:00
|
|
|
|
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-11 00:35:25 +08:00
|
|
|
modules := mctx.CreateVariations(variations...)
|
2020-02-13 09:13:25 +08:00
|
|
|
for i, mod := range modules {
|
apex_available tracks static dependencies
This change fixes a bug that apex_available is not enforced for static
dependencies. For example, a module with 'apex_available:
["//apex_available:platform"]' was able to be statically linked to any
APEX. This was happening because the check was done on the modules that
are actually installed to an APEX. Static dependencies of the modules
were not counted as they are not installed to the APEX as files.
Fixing this bug by doing the check by traversing the tree in the method
checkApexAvailability.
This change includes a few number of related changes:
1) DepIsInSameApex implementation for cc.Module was changed as well.
Previuosly, it returned false only when the dependency is actually a
stub variant of a lib. Now, it returns false when the dependency has one
or more stub variants. To understand why, we need to recall that when
there is a dependency to a lib having stubs, we actually create two
dependencies: to the non-stub variant and to the stub variant during the
DepsMutator phase. And later in the build action generation phase, we
choose one of them depending on the context. Also recall that an APEX
variant is created only when DepIsInSameApex returns true. Given these,
with the previous implementatin of DepIsInSameApex, we did create apex
variants of the non-stub variant of the dependency, while not creating
the apex variant for the stub variant. This is not right; we needlessly
created the apex variant. The extra apex variant has caused no harm so
far, but since the apex_available check became more correct, it actually
breaks the build. To fix the issue, we stop creating the APEX variant
both for non-stub and stub variants.
2) platform variant is created regardless of the apex_available value.
This is required for the case when a library X that provides stub is in
an APEX A and is configured to be available only for A. In that case,
libs in other APEX can't use the stub library since the stub library is
mutated only for apex A. By creating the platform variant for the stub
library, it can be used from outside as the default dependency variation
is 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-31 01:49:53 +08:00
|
|
|
platformVariation := i == 0
|
2020-02-13 09:13:25 +08:00
|
|
|
if platformVariation && !mctx.Host() && !mod.(ApexModule).AvailableFor(AvailableToPlatform) {
|
2020-08-07 05:34:42 +08:00
|
|
|
// Do not install the module for platform, but still allow it to output
|
|
|
|
// uninstallable AndroidMk entries in certain cases when they have
|
|
|
|
// side effects.
|
|
|
|
mod.MakeUninstallable()
|
2020-02-13 09:13:25 +08:00
|
|
|
}
|
|
|
|
if !platformVariation {
|
|
|
|
mod.(ApexModule).apexModuleBase().ApexProperties.Info = m.apexVariations[i-1]
|
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-11 00:35:25 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return modules
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
var apexData OncePer
|
|
|
|
var apexNamesMapMutex sync.Mutex
|
2019-02-05 03:22:08 +08:00
|
|
|
var apexNamesKey = NewOnceKey("apexNames")
|
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-11 00:35:25 +08:00
|
|
|
|
|
|
|
// This structure maintains the global mapping in between modules and APEXes.
|
|
|
|
// Examples:
|
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 17:02:45 +08:00
|
|
|
//
|
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-11 00:35:25 +08:00
|
|
|
// apexNamesMap()["foo"]["bar"] == true: module foo is directly depended on by APEX bar
|
|
|
|
// apexNamesMap()["foo"]["bar"] == false: module foo is indirectly depended on by APEX bar
|
|
|
|
// apexNamesMap()["foo"]["bar"] doesn't exist: foo is not built for APEX bar
|
|
|
|
func apexNamesMap() map[string]map[string]bool {
|
2019-02-05 03:22:08 +08:00
|
|
|
return apexData.Once(apexNamesKey, func() interface{} {
|
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 17:02:45 +08:00
|
|
|
return make(map[string]map[string]bool)
|
|
|
|
}).(map[string]map[string]bool)
|
|
|
|
}
|
|
|
|
|
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-11 00:35:25 +08:00
|
|
|
// Update the map to mark that a module named moduleName is directly or indirectly
|
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-12 06:53:12 +08:00
|
|
|
// depended on by the specified APEXes. Directly depending means that a module
|
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-11 00:35:25 +08:00
|
|
|
// is explicitly listed in the build definition of the APEX via properties like
|
|
|
|
// native_shared_libs, java_libs, etc.
|
2020-07-22 14:17:19 +08:00
|
|
|
func UpdateApexDependency(apex ApexInfo, moduleName string, directDep bool) {
|
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-11 00:35:25 +08:00
|
|
|
apexNamesMapMutex.Lock()
|
|
|
|
defer apexNamesMapMutex.Unlock()
|
2020-07-22 14:17:19 +08:00
|
|
|
apexesForModule, ok := apexNamesMap()[moduleName]
|
|
|
|
if !ok {
|
|
|
|
apexesForModule = make(map[string]bool)
|
|
|
|
apexNamesMap()[moduleName] = apexesForModule
|
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 17:02:45 +08:00
|
|
|
}
|
2020-08-14 02:24:56 +08:00
|
|
|
apexesForModule[apex.ApexVariationName] = apexesForModule[apex.ApexVariationName] || directDep
|
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 17:02:45 +08:00
|
|
|
}
|
|
|
|
|
2019-12-17 11:47:13 +08:00
|
|
|
// TODO(b/146393795): remove this when b/146393795 is fixed
|
|
|
|
func ClearApexDependency() {
|
|
|
|
m := apexNamesMap()
|
|
|
|
for k := range m {
|
|
|
|
delete(m, k)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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-11 00:35:25 +08:00
|
|
|
// Tests whether a module named moduleName is directly depended on by an APEX
|
|
|
|
// named apexName.
|
|
|
|
func DirectlyInApex(apexName string, moduleName string) bool {
|
|
|
|
apexNamesMapMutex.Lock()
|
|
|
|
defer apexNamesMapMutex.Unlock()
|
|
|
|
if apexNames, ok := apexNamesMap()[moduleName]; ok {
|
|
|
|
return apexNames[apexName]
|
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 17:02:45 +08:00
|
|
|
}
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
2019-01-16 03:53:23 +08:00
|
|
|
type hostContext interface {
|
|
|
|
Host() bool
|
|
|
|
}
|
|
|
|
|
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-11 00:35:25 +08:00
|
|
|
// Tests whether a module named moduleName is directly depended on by any APEX.
|
2019-01-16 03:53:23 +08:00
|
|
|
func DirectlyInAnyApex(ctx hostContext, moduleName string) bool {
|
|
|
|
if ctx.Host() {
|
|
|
|
// Host has no APEX.
|
|
|
|
return 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-11 00:35:25 +08:00
|
|
|
apexNamesMapMutex.Lock()
|
|
|
|
defer apexNamesMapMutex.Unlock()
|
|
|
|
if apexNames, ok := apexNamesMap()[moduleName]; ok {
|
|
|
|
for an := range apexNames {
|
|
|
|
if apexNames[an] {
|
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 17:02:45 +08:00
|
|
|
return true
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 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-11 00:35:25 +08:00
|
|
|
// Tests whether a module named module is depended on (including both
|
|
|
|
// direct and indirect dependencies) by any APEX.
|
|
|
|
func InAnyApex(moduleName string) bool {
|
|
|
|
apexNamesMapMutex.Lock()
|
|
|
|
defer apexNamesMapMutex.Unlock()
|
|
|
|
apexNames, ok := apexNamesMap()[moduleName]
|
|
|
|
return ok && len(apexNames) > 0
|
|
|
|
}
|
|
|
|
|
|
|
|
func GetApexesForModule(moduleName string) []string {
|
|
|
|
ret := []string{}
|
|
|
|
apexNamesMapMutex.Lock()
|
|
|
|
defer apexNamesMapMutex.Unlock()
|
|
|
|
if apexNames, ok := apexNamesMap()[moduleName]; ok {
|
|
|
|
for an := range apexNames {
|
|
|
|
ret = append(ret, an)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return ret
|
2018-12-07 22:08:36 +08:00
|
|
|
}
|
|
|
|
|
2018-10-02 23:38:19 +08:00
|
|
|
func InitApexModule(m ApexModule) {
|
|
|
|
base := m.apexModuleBase()
|
|
|
|
base.canHaveApexVariants = true
|
|
|
|
|
|
|
|
m.AddProperties(&base.ApexProperties)
|
|
|
|
}
|
2020-04-28 00:08:37 +08:00
|
|
|
|
|
|
|
// A dependency info for a single ApexModule, either direct or transitive.
|
|
|
|
type ApexModuleDepInfo struct {
|
|
|
|
// Name of the dependency
|
|
|
|
To string
|
|
|
|
// List of dependencies To belongs to. Includes APEX itself, if a direct dependency.
|
|
|
|
From []string
|
|
|
|
// Whether the dependency belongs to the final compiled APEX.
|
|
|
|
IsExternal bool
|
2020-04-28 01:53:18 +08:00
|
|
|
// min_sdk_version of the ApexModule
|
|
|
|
MinSdkVersion string
|
2020-04-28 00:08:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// A map of a dependency name to its ApexModuleDepInfo
|
|
|
|
type DepNameToDepInfoMap map[string]ApexModuleDepInfo
|
|
|
|
|
|
|
|
type ApexBundleDepsInfo struct {
|
2020-05-14 06:44:03 +08:00
|
|
|
flatListPath OutputPath
|
|
|
|
fullListPath OutputPath
|
2020-04-28 00:08:37 +08:00
|
|
|
}
|
|
|
|
|
2020-04-28 21:57:42 +08:00
|
|
|
type ApexBundleDepsInfoIntf interface {
|
|
|
|
Updatable() bool
|
2020-04-28 01:07:06 +08:00
|
|
|
FlatListPath() Path
|
2020-04-28 00:08:37 +08:00
|
|
|
FullListPath() Path
|
|
|
|
}
|
|
|
|
|
2020-04-28 01:07:06 +08:00
|
|
|
func (d *ApexBundleDepsInfo) FlatListPath() Path {
|
|
|
|
return d.flatListPath
|
|
|
|
}
|
|
|
|
|
2020-04-28 00:08:37 +08:00
|
|
|
func (d *ApexBundleDepsInfo) FullListPath() Path {
|
|
|
|
return d.fullListPath
|
|
|
|
}
|
|
|
|
|
2020-04-28 01:07:06 +08:00
|
|
|
// Generate two module out files:
|
|
|
|
// 1. FullList with transitive deps and their parents in the dep graph
|
|
|
|
// 2. FlatList with a flat list of transitive deps
|
2020-04-28 01:53:18 +08:00
|
|
|
func (d *ApexBundleDepsInfo) BuildDepsInfoLists(ctx ModuleContext, minSdkVersion string, depInfos DepNameToDepInfoMap) {
|
2020-04-28 01:07:06 +08:00
|
|
|
var fullContent strings.Builder
|
|
|
|
var flatContent strings.Builder
|
|
|
|
|
2020-04-28 01:53:18 +08:00
|
|
|
fmt.Fprintf(&flatContent, "%s(minSdkVersion:%s):\\n", ctx.ModuleName(), minSdkVersion)
|
2020-04-28 00:08:37 +08:00
|
|
|
for _, key := range FirstUniqueStrings(SortedStringKeys(depInfos)) {
|
|
|
|
info := depInfos[key]
|
2020-04-28 01:53:18 +08:00
|
|
|
toName := fmt.Sprintf("%s(minSdkVersion:%s)", info.To, info.MinSdkVersion)
|
2020-04-28 00:08:37 +08:00
|
|
|
if info.IsExternal {
|
|
|
|
toName = toName + " (external)"
|
|
|
|
}
|
2020-04-28 01:07:06 +08:00
|
|
|
fmt.Fprintf(&fullContent, "%s <- %s\\n", toName, strings.Join(SortedUniqueStrings(info.From), ", "))
|
|
|
|
fmt.Fprintf(&flatContent, " %s\\n", toName)
|
2020-04-28 00:08:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
d.fullListPath = PathForModuleOut(ctx, "depsinfo", "fulllist.txt").OutputPath
|
|
|
|
ctx.Build(pctx, BuildParams{
|
|
|
|
Rule: WriteFile,
|
|
|
|
Description: "Full Dependency Info",
|
|
|
|
Output: d.fullListPath,
|
|
|
|
Args: map[string]string{
|
2020-04-28 01:07:06 +08:00
|
|
|
"content": fullContent.String(),
|
|
|
|
},
|
|
|
|
})
|
|
|
|
|
|
|
|
d.flatListPath = PathForModuleOut(ctx, "depsinfo", "flatlist.txt").OutputPath
|
|
|
|
ctx.Build(pctx, BuildParams{
|
|
|
|
Rule: WriteFile,
|
|
|
|
Description: "Flat Dependency Info",
|
|
|
|
Output: d.flatListPath,
|
|
|
|
Args: map[string]string{
|
|
|
|
"content": flatContent.String(),
|
2020-04-28 00:08:37 +08:00
|
|
|
},
|
|
|
|
})
|
|
|
|
}
|
2020-04-15 10:03:39 +08:00
|
|
|
|
|
|
|
// TODO(b/158059172): remove minSdkVersion allowlist
|
|
|
|
var minSdkVersionAllowlist = map[string]int{
|
|
|
|
"adbd": 30,
|
|
|
|
"android.net.ipsec.ike": 30,
|
|
|
|
"androidx-constraintlayout_constraintlayout-solver": 30,
|
|
|
|
"androidx.annotation_annotation": 28,
|
|
|
|
"androidx.arch.core_core-common": 28,
|
|
|
|
"androidx.collection_collection": 28,
|
|
|
|
"androidx.lifecycle_lifecycle-common": 28,
|
|
|
|
"apache-commons-compress": 29,
|
|
|
|
"bouncycastle_ike_digests": 30,
|
|
|
|
"brotli-java": 29,
|
|
|
|
"captiveportal-lib": 28,
|
|
|
|
"flatbuffer_headers": 30,
|
|
|
|
"framework-permission": 30,
|
|
|
|
"framework-statsd": 30,
|
|
|
|
"gemmlowp_headers": 30,
|
|
|
|
"ike-internals": 30,
|
|
|
|
"kotlinx-coroutines-android": 28,
|
|
|
|
"kotlinx-coroutines-core": 28,
|
|
|
|
"libadb_crypto": 30,
|
|
|
|
"libadb_pairing_auth": 30,
|
|
|
|
"libadb_pairing_connection": 30,
|
|
|
|
"libadb_pairing_server": 30,
|
|
|
|
"libadb_protos": 30,
|
|
|
|
"libadb_tls_connection": 30,
|
|
|
|
"libadbconnection_client": 30,
|
|
|
|
"libadbconnection_server": 30,
|
|
|
|
"libadbd_core": 30,
|
|
|
|
"libadbd_services": 30,
|
|
|
|
"libadbd": 30,
|
|
|
|
"libapp_processes_protos_lite": 30,
|
|
|
|
"libasyncio": 30,
|
|
|
|
"libbrotli": 30,
|
|
|
|
"libbuildversion": 30,
|
|
|
|
"libcrypto_static": 30,
|
|
|
|
"libcrypto_utils": 30,
|
|
|
|
"libdiagnose_usb": 30,
|
|
|
|
"libeigen": 30,
|
|
|
|
"liblz4": 30,
|
|
|
|
"libmdnssd": 30,
|
|
|
|
"libneuralnetworks_common": 30,
|
|
|
|
"libneuralnetworks_headers": 30,
|
|
|
|
"libneuralnetworks": 30,
|
|
|
|
"libprocpartition": 30,
|
|
|
|
"libprotobuf-java-lite": 30,
|
|
|
|
"libprotoutil": 30,
|
|
|
|
"libqemu_pipe": 30,
|
|
|
|
"libstats_jni": 30,
|
|
|
|
"libstatslog_statsd": 30,
|
|
|
|
"libstatsmetadata": 30,
|
|
|
|
"libstatspull": 30,
|
|
|
|
"libstatssocket": 30,
|
|
|
|
"libsync": 30,
|
|
|
|
"libtextclassifier_hash_headers": 30,
|
|
|
|
"libtextclassifier_hash_static": 30,
|
|
|
|
"libtflite_kernel_utils": 30,
|
|
|
|
"libwatchdog": 29,
|
|
|
|
"libzstd": 30,
|
|
|
|
"metrics-constants-protos": 28,
|
|
|
|
"net-utils-framework-common": 29,
|
|
|
|
"permissioncontroller-statsd": 28,
|
|
|
|
"philox_random_headers": 30,
|
|
|
|
"philox_random": 30,
|
|
|
|
"service-permission": 30,
|
|
|
|
"service-statsd": 30,
|
|
|
|
"statsd-aidl-ndk_platform": 30,
|
|
|
|
"statsd": 30,
|
|
|
|
"tensorflow_headers": 30,
|
|
|
|
"xz-java": 29,
|
|
|
|
}
|
|
|
|
|
|
|
|
// Function called while walking an APEX's payload dependencies.
|
|
|
|
//
|
|
|
|
// Return true if the `to` module should be visited, false otherwise.
|
|
|
|
type PayloadDepsCallback func(ctx ModuleContext, from blueprint.Module, to ApexModule, externalDep bool) bool
|
|
|
|
|
|
|
|
// UpdatableModule represents updatable APEX/APK
|
|
|
|
type UpdatableModule interface {
|
|
|
|
Module
|
|
|
|
WalkPayloadDeps(ctx ModuleContext, do PayloadDepsCallback)
|
|
|
|
}
|
|
|
|
|
|
|
|
// CheckMinSdkVersion checks if every dependency of an updatable module sets min_sdk_version accordingly
|
|
|
|
func CheckMinSdkVersion(m UpdatableModule, ctx ModuleContext, minSdkVersion int) {
|
|
|
|
// do not enforce min_sdk_version for host
|
|
|
|
if ctx.Host() {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
// do not enforce for coverage build
|
|
|
|
if ctx.Config().IsEnvTrue("EMMA_INSTRUMENT") || ctx.DeviceConfig().NativeCoverageEnabled() || ctx.DeviceConfig().ClangCoverageEnabled() {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
// do not enforce deps.min_sdk_version if APEX/APK doesn't set min_sdk_version or
|
|
|
|
// min_sdk_version is not finalized (e.g. current or codenames)
|
|
|
|
if minSdkVersion == FutureApiLevel {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
m.WalkPayloadDeps(ctx, func(ctx ModuleContext, from blueprint.Module, to ApexModule, externalDep bool) bool {
|
|
|
|
if externalDep {
|
|
|
|
// external deps are outside the payload boundary, which is "stable" interface.
|
|
|
|
// We don't have to check min_sdk_version for external dependencies.
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
if am, ok := from.(DepIsInSameApex); ok && !am.DepIsInSameApex(ctx, to) {
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
if err := to.ShouldSupportSdkVersion(ctx, minSdkVersion); err != nil {
|
|
|
|
toName := ctx.OtherModuleName(to)
|
|
|
|
if ver, ok := minSdkVersionAllowlist[toName]; !ok || ver > minSdkVersion {
|
|
|
|
ctx.OtherModuleErrorf(to, "should support min_sdk_version(%v) for %q: %v. Dependency path: %s",
|
|
|
|
minSdkVersion, ctx.ModuleName(), err.Error(), ctx.GetPathString(false))
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return true
|
|
|
|
})
|
|
|
|
}
|