Visibility rules can be 'inherited' in one of two ways. Either from
defaults or from a module that called ctx.CreateModule(...).
Previously, in both cases the inheriting module could only append
additional visibility rules to the end of the inherited rules. That
made it impossible to restrict the visibility by removing or ignore
inherited rules.
The //visibility:override rectifies that by allowing the inheriting
module to ignore all the rules that they would have inherited. It can
only go at the beginning of a list of rules specified in a module but
after defaults are applied it can end up in the middle of a list of
rules. In that case it behaves as if all the rules up to and including
the //visibility:override rule were discarded.
It can be used with //visibility:private to override
//visibility:public and vice versa.
Bug: 155787200
Test: m nothing
Change-Id: I8a9c9c5a1bdceaee387c08864ae2b34629e0d46f
Checks the syntax of the Android.bp file generated for the sdk
snapshot. While this will not detect all possible problems with the
generated Android.bp file it will detect some and it is far better to
detect those issues during generation than when it is unpacked and
used.
Bug: 155628860
Test: m nothing
Change-Id: Ieec86a7a49fa2e3bd8b9f83aca540114232a3476
Adds a filter mechanism that can exclude property values from being
included in the common value extraction. That is needed to prevent the
snapshot mechanism from generating invalid output for properties that
are ignored on host (and have their values cleared) and which are not
tagged with `android:"arch_variant"`.
Changes:
* Updates the documentation of SdkMemberType to explain what effect
the 'ignored-on-host' tag has.
* Adds some tests for this new mechanism.
Bug: 155628860
Test: m nothing
Change-Id: Ibafdb6e921ba5abe505bd8a91ca5a1d9c9b5d0cb
Previously, the snapshot code did not know whether a specific property
could be arch specific or not and assumed that they all were which
meant that it could generate snapshots containing arch specific values
for properties that are not arch specific and so would fail when
unpacked.
This change requires arch specific fields in SdkMemberProperties to be
tagged as such using `android:"arch_variant"` (just as in module input
property structures). Any property without that must have properties
that are common across all variants.
Bug: 155628860
Test: m nothing
Change-Id: I3df60f0b53ba02ec2c55a80c7da058eac5909d26
* changes:
Revert "Detect invalid arch specific properties in snapshot"
Revert "Adds support for 'ignored-on-host'"
Revert "Fix snapshot of a host/device cc_library with stubs"
Revert submission 1302576
Bug: 156054601
Reason for revert: Presumed root cause of build break.
Reverted Changes:
Ifc8116e11:Detect invalid arch specific properties in snapsho...
I7ebd33307:Adds support for 'ignored-on-host'
I167b47a13:Fix snapshot of a host/device cc_library with stub...
Change-Id: Id7eba0bdde5c579e10e9b42d94a7cfab5f34995f
Revert submission 1302576
Bug: 156054601
Reason for revert: Presumed root cause of build break.
Reverted Changes:
Ifc8116e11:Detect invalid arch specific properties in snapsho...
I7ebd33307:Adds support for 'ignored-on-host'
I167b47a13:Fix snapshot of a host/device cc_library with stub...
Change-Id: I2a7ac0ef0232177eefc26542c11dc675d6f4cab2
Adds a filter mechanism that can exclude property values from being
included in the common value extraction. That is needed to prevent the
snapshot mechanism from generating invalid output for properties that
are ignored on host (and have their values cleared) and which are not
tagged with `android:"arch_variant"`.
Changes:
* Updates the documentation of SdkMemberType to explain what effect
the 'ignored-on-host' tag has.
* Adds some tests for this new mechanism.
Bug: 155628860
Test: m nothing
Change-Id: I7ebd333079619dba546bc8c4911d567e0287b676
Previously, the snapshot code did not know whether a specific property
could be arch specific or not and assumed that they all were which
meant that it could generate snapshots containing arch specific values
for properties that are not arch specific and so would fail when
unpacked.
This change requires arch specific fields in SdkMemberProperties to be
tagged as such using `android:"arch_variant"` (just as in module input
property structures). Any property without that must have properties
that are common across all variants.
Bug: 155628860
Test: m nothing
Change-Id: Ifc8116e11d987cfe7aec2eeaa964f3bbf36b5dc2
The method is a thin wrapper around GetWalkPath and GetTagPath to make
it easy to construct a string representation of the current path.
It was originally inlined in the apex package. This change makes it a
function and moves it to the android package so make it more useful.
Bug: N/A
Test: m
Change-Id: I7e2bc2074baed759d67d9097151c9ac10e34ed31
Previously, the only way for a module type to create modules (other
than defining its own mutator) was to register a LoadHook. However,
that is called before defaults are applied so any properties used in
that hook cannot take advantage of defaults, e.g. java_sdk_library
cannot use defaults to set its sdk_version property and have that
affect its child modules.
This change adds a new SetDefaultableHook() to DefaultableModule to
register a hook that is called after any defaults have been applied.
Also adds some tests to ensure that errors in the visibility property
introduced in a DefaultableHook are reported in the gather phase of
visibility processing.
A follow up change will switch java_sdk_library to use that instead
of the AddLoadHook() mechanism.
Bug: 155295806
Test: m checkapi
Change-Id: I13df3115f9e225f7324b6725eaeb16a78cc2538a
A follow up change will add a mechanism for a module to register a hook
that is called after any defaults have been applied. That is intended
for use by modules like java_sdk_library that create child modules that
are dependent upon properties that could be supplied by defaults.
Creating those child modules after prebuilts mutators are run will
cause problems if those child modules clash with prebuilts modules.
Moving the prebuilts mutators after the defaults mutators will fix
that.
Tests are currently being run with the mutators in different orders so
this change also cleans that up so they are consistent with the actual
code that is being run.
Bug: 155295806
Test: m checkbuild
Change-Id: I825c6df09058fb3a45db196661959eb332aca2f3
This was not previously possible due to LoadHooks being run after the
module was registered.
Bug: 155462403
Test: m nothing
Change-Id: Ia8383b9d1272bb12c8a83948753a0e4b0d98a650
This adds gcov coverage support for Rust device library and binary
modules (including test modules). Support is provided to pass Rust
static library gcno files to CC modules and visa versa.
Additional changes:
* Begin mutator added for Rust modules.
* SuffixInList added to android package.
* CoverageEnabled added to Coverage interface.
* CoverageFiles added to LinkableLibrary interface.
* Fix in coverage mutator for non-CC modules which marked the wrong
variant as the coverage variant.
* Added coverage libraries to the cc.GatherRequiredDepsForTest.
Bug: 146448203
Test: NATIVE_COVERAGE=true COVERAGE_PATHS='*' m -j <rust_module>
Change-Id: If20728bdde42a1dd544a35a40f0d981b80a5835f
Compared to full list, flat list drops dependency edges and simply
lists all transitive dependencies for a top-level apex bundle.
Bug: 149622332
Test: m, manually build flatlist
Change-Id: Ibd521c96b7aeab90b95965c1b524e0a0152aaf5a
Move depsInfo into android for easier sharing with APK code.
Bug: 149622332
Test: m, diff'ing outputs for conscrypt module.
Change-Id: If0ee967d37425540e69b4ce9304229d9f2cd86bd
Previously, errors that were found when splitting visibility rules were
only reported in the check phase and simply ignored during the gather
phase. That was because every visibility property that was processed in
the gather phase had already been checked in the check phase. However,
that is not strictly true as it has always been possible to add a
mutator between the check and gather phases that creates a module with
invalid visibility properties that will just be ignored. Fortunately,
that has not happened.
A follow up commit will add the capability to create modules after the
defaults have been applied which means the chances of invalid visibility
properties being ignored will increase.
This change makes both phases report any errors they find. It will not
have any impact on existing code as if any errors are reported in the
check phase then the build will exit before the gather phase. It will
prevent any invalid visibility errors from being ignored.
Bug: 155295806
Test: m nothing
Change-Id: I101fa6b03d2530b16e4394a9e466fead48be0ff0
Adds a couple of new methods to manage visibility property instances to
reduce duplication and encapsulate the implementation slightly better.
The AddVisibilityProperty method is exported as it will be needed by
other packages in follow up commits.
Bug: 155295806
Test: m nothing
Change-Id: Ic1a9bb1e151fc6ae65761344fd210b4e4ba74fbc
The first component is the apex name, or a special name "platform"
if the boot jar is a platform jar rather than a part of some apex.
This is a prerequisite change for moving core-icu4j to a separate
com.android.i18n apex.
Old one-column format is still supported, but all unqualified
components of PRODUCT_BOOT_JARS get "platform:" prepended to them
after reading the product makefiles.
Test: aosp_walleye-userdebug boots
Bug: 138994281
Change-Id: Ic229159fdcdaf6182210a53b63850a389dd786fc
This change adds 'test_for' property to cc_test_* types. The property is
used to mark a module as a test for one or more APEXes, in which case
the module has accecss to the private part of the listed APEXes. For
example, the module is linked with the actrual shared library in the
APEX instead of the stub of the shared library.
Exempt-From-Owner-Approval: already +2'ed by owner
Bug: 129539670
Bug: 153046163
Test: m
Change-Id: I45ed0d7a15540b0d69b2a3b8d9c4cb202adff6f2
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
For a given variant of a module that implements ApexModule interface,
the "updatable" property tests if this variant comes from an updatable
apex. For platform variants it is always false.
Test: lunch aosp_walleye-userdebug && m nothing
Bug: 138994281
Change-Id: I2d4c54fb397e29dc9b3203be7fb17be4536529f7
This exposes test func on ValueMatcher and helpers relevant for testing neverallows.
Bug: 153333044
Test: m
Change-Id: Ied07cd33afa537f9d7aa3c33e59f4ac985901a0f
It has been wrong to split ALL_VERSIONS into exclusive two sets of
before/after TARGET_PLATFORM_VERSION.
And PLATFORM_VERSION_ALL_CODENAMES supports all *active* list of
non-finalized codenames.
Bug: 152960049
Test: m
Exempt-From-Owner-Approval: cp from master
Merged-In: I78ca88758998e440bea72ba2d56d90eea3ec99ae
Change-Id: I78ca88758998e440bea72ba2d56d90eea3ec99ae
(cherry picked from commit 424175d72a)
Allow the platform stubs to specify sdk_version: none,
and add generic support for a regexp matcher.
Bug: 144149403
Test: m
Change-Id: Icaece0d9797bace8ae9741f7a029b9ea57fcbbb9
Apex can use codenames like "Q", "R" for its min_sdk_version property.
Also, cc_library can use codenames for its stubs.versions.
Bug: 152655956
Test: m
Merged-In: I077ad7b2ac5d90b4c8708921e43846206f05ba70
Change-Id: I077ad7b2ac5d90b4c8708921e43846206f05ba70
(cherry picked from commit 29e91d2121)
When a source and a prebuilt module are present in the same build a
dependency is added from the source module to the prebuilt module.
Previously, the code for generating the APEX did not recognize that
tag and in some cases (e.g. for cc_(prebuilt_)library_shared) will
fail the build.
This change:
1) Adds a test to reproduce the problem.
2) Improves the debug message by pretty printing the tag.
3) Adds a new ExcludeFromApexContents interface that can be implemented
by a tag to declare that it should be excluded from the APEX
contents.
4) Ignores tags that implement that interface when generating APEX
contents.
5) Implements that interface on prebuiltDependencyTag to fix the
test.
Bug: 153326844
Test: m nothing
Change-Id: I9dd4312c4f995c816c0a31d8d733eb5d7f56e1ea
Having dependency tags in the dependency path that shows why a specific
module is considered part of an apex makes it easier to understand why
that is the case and detect possible issues.
Bug: 152762638
Test: m nothing
Change-Id: Iba2a8a5a6abe03dadee456e760aa4373cd00c07b
This is to guard against the potential situation when someone adds
updatable modules to the list of boot jars by mistake.
Test: aosp_walleye-userdebug builds.
Test: Manually break the checks and observe the errors:
- move updatable module 'conscrypt' from
PRODUCT_UPDATABLE_BOOT_JARS to ART_APEX_JARS:
internal error: module 'conscrypt' from updatable apex 'com.android.conscrypt' is not allowed in the ART boot image
- add updatable module 'conscrypt' to ART_APEX_JARS
(but do not remove it from PRODUCT_UPDATABLE_BOOT_JARS):
error: A jar in PRODUCT_UPDATABLE_BOOT_JARS must not be in PRODUCT_BOOT_JARS, but conscrypt is.
- move updatable module 'framework-tethering' from
PRODUCT_UPDATABLE_BOOT_JARS to PRODUCT_BOOT_JARS:
internal error: module 'framework-tethering' from updatable apex 'com.android.tethering' is not allowed in the framework boot image
- add non-updatable (in AOSP) module 'android.net.ipsec.ike'
to PRODUCT_BOOT_JARS:
internal error: failed to find a dex jar path for module 'com.android.ipsec.ike', note that some jars may be filtered out by module constraints
Bug: 147579140
Change-Id: I25ca2f52530fcfa1f9823b2cfa3485db9c0d0db1
The DepIsInSameApex() and RequiredSdks() methods were defined in a few
places to avoid having to depend on the whole ApexModule/SdkAware
interfaces directly. However, that has a couple of issues:
1) It duplicates functionality making it difficult to change, changes
to the definitions outside the main interfaces do not cause compile
time failures, instead they result in a runtime change in behavior
which can be difficult to debug.
2) IDE navigation (specifically in Intellij) does not detect that the
duplicate definitions can resolve to the definitions in the main
interface.
This change extracts the methods into their own interfaces and reuses
those interfaces instead of duplicating the methods to fix both of
these issues.
Bug: 152878661
Test: m nothing
Change-Id: I0cfdf342a14eb0bfb82b1bd17e0633d81c7facfb
Revert submission 1242911-sdk_version_variant
Reason for revert: b/153394225
Reverted Changes:
Ife99745fb:Use libnativewindow for platform variant of libagq...
I1bae84c43:Use libnativewindow for platform variant of androi...
I6e6021ed3:Use stl to depend on libc++
Ife99745fb:Use libnativewindow for platform variant of libRSS...
I2c9f439b9:Fix static dependency on libprotobuf-cpp-lite-ndk
Iff2aff9cf:Set sdk_version for cc_genrules used by modules wi...
I7d72934aa:Add sdk mutator for native modules
Ief378a007:Use sdk variant of Soong modules when LOCAL_SDK_VE...
Bug: 149591340
Change-Id: I798fa902c779469c6382b6699351e5d12bf14785
Fixes: 153394225
blueprint.writeAllModuleActions attemts to sort modules by name, and
sorting them assumes that each module's name is unique. Although
soong_config_module_type_import modules will not generate anything,
their names should be unique, too for that reason.
Fixes: 150421585
Test: m nothing
Change-Id: I6782e42c129dc3b0fc7649ce97d5f94effc63fa7
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 7406660685)
Exempt-From-Owner-Approval: cp from internal
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
Compiling native modules against the NDK disables platform features
like ASAN. For anything shipped on the system image there is no
reason to compile against the NDK. Add a new mutator to Soong that
creates a platform and an SDK variant for modules that set
sdk_version, and ignore sdk_version for the platform variant. The
SDK variant will be used for embedding in APKs that may be installed
on older platforms. Apexes use their own variants that enforce
backwards compatibility.
Test: sdk_test.go
Test: TestJNIPackaging
Bug: 149591340
Change-Id: I7d72934aaee2e1326cc0ba5f29f51f14feec4521
The default build is to enable optimization for all of module.
In order to have the feasibility to the owners of the modules,
to create product_variables.eng.optimize.enabled let the owners
to have the choice to decide whether the build enable the optimization
or not.
Test: atest -m # build soong
Test: # follow Developing for Soong & setup GOPATH
# to run the new tests in variables_test.go
cd $GOPATH; \
go test android/soong/android
Test: #1. change frameworks/base/packages/SystemUI/Android.bp to change
product_variables.eng.optimize.enabled = false;
#2. source build/setupenv.sh;
#3. lunch aosp_x86-eng; make -j16 SystemUI
#4. lunch aosp_x86-userdebug; make -j16 SystemUI
#5. aosp_x86-eng should be bigger than aosp_x86-userdebug
Bug: 130259652
Change-Id: Ie62c35458ca91d66ec65bda58d315fb971139849
This CL fixes a bug with RuleBuilder's handling of remoteable actions.
It adds a new type of pool to identify remoteable rules by the android
module context. The pool is then set to nil to actually run actions at
NINJA_REMOTE_NUM_JOBS parallelism.
Test: built aosp crosshatch userdebug
Change-Id: I29452f6fc7a161b94189731e3e3cc1f34907b80c
The partition tag helps merge_target_files.py determine
which apexkeys.txt to select from the framework partial
target files and which to select from the vendor partial
target files. The partition tag is the pysical partition
name, for example, a system_ext module on a device where
system_ext is at system/system_ext has a system
partition tag.
Bug: 138942268
Change-Id: Ia07887b34f1aa77dae94ef23610dfef83c1a5849
There are some cases that aren't handled with the existing variable
types for booleans or known lists of strings. Similarly to our
product_variables that uses %s / %d for things like
PLATFORM_SDK_VERSION, allow vendors to define their own config variables
to be substituted into properties.
For example, some of the makefiles that I've attempted to convert had
the option to pass in version numbers from the board, or the default
display size:
-DDISPLAY_VERSION=550
-DDISP_H=1080
These examples happen to be integers, but since our configuration
language (make) doesn't support numbers, %s works just as well.
This change will allow the above to be represented using:
soong_config_module_type {
name: "acme_cc_defaults",
module_type: "cc_defaults",
config_namespace: "acme",
value_variables: [
"DISPLAY_VERSION",
"DISP_H",
],
properties: ["cflags"],
}
acme_cc_defaults {
name: "my_defaults",
soong_config_variables: {
DISPLAY_VERSION: {
cflags: ["-DDISPLAY_VERSION=%s"],
},
DISP_H: {
cflags: ["-DDISP_H=%s"],
}
},
}
Test: built-in tests
Change-Id: I18f35746b5cc39c304a136980249e886d38c6df6
This causes the compiler to emit some additional debug infomation that
will be used for sampling PGO. These debug infomation will get stripped
so it only affects intermediate files.
Test: build
Bug: 79161490
Change-Id: Ie4d1d5ffbd311ba6e268cb94a618f5272be246ef
Using a lot of boolean variables can become very verbose without adding
really any new information:
variables: ["a", "b", "c"],
}
soong_config_bool_variable {
name: "a",
}
soong_config_bool_variable {
name: "b",
}
soong_config_bool_variable {
name: "c",
}
Now turns into:
bool_variables: ["a", "b", "c"],
}
Test: built-in tests
Change-Id: If5455a38433431c7ecbce1e5b32cfbb47f42602a
Migrates system modules and droid stubs over to use the new API for
creating the snapshot modules and removes the old API.
Test: m nothing
Change-Id: Ia825767f1f7ee77f68cfe00f53e09e6f6bfa027f
Previously, java snapshot properties (java_library and java_test)
relied on the properties not being optimized when there was a single os
type and instead being added directly to the common os type properties.
However, that means that the behavior is inconsistent for other member
types depending on whether there was one os type or not.
This change updates the java sdk member handling to support
optimization. This involved:
1) Adding AidlIncludeDirs field to librarySdkMemberProperties to
specify the aidl include dirs instead of extracting that from the
library field.
2) Renaming jarToExport to JarToExport (in both
library/testSdkMemberProperties)to allow it to be optimized.
3) Adding MemberType() and Name() methods to SdkMemberPropertiesContext
to avoid having to store the former in the properties struct and
retrieve the latter from the library/test fields.
4) Removing the now unused library/test fields from the properties
structures.
5) Separating the processing of the jar/test config in
AddToPropertySet(...) as they may be optimized separately.
6) Ditto for the jar/aidl include dirs.
7) While doing this work I noticed that although the contents of the
aidl include dirs are copied into the snapshot the java_import does
not make use of them. Raised bug 151933053 and added TODO to track
that work.
Bug: 142935992
Test: m nothing
Change-Id: Iba9799e111ca5672b2133568163d8c49837ba9cd
Previously passing additional information to the implementations of
AddPrebuiltModule() or the SdkMemberProperties interface would have
required making changes to the API. This change added an
SdkMemberContext object into which additional information can easily
be added without requiring changes to existing implementations.
The BuildSnapshot() method was not modified because it is deprecated
and will be removed in a follow up change.
It also switches the API from passing variants as android.SdkAware to
android.Module. That is for a couple of reasons:
1) SdkAware is designed for managing the relationship between the
module and the SDK, not for generating the output snapshot. As such
there is nothing in SdkAware that is needed for generating the
output snapshot.
2) Accepting android.Module instead makes it easier to use the
underlying code for generating the snapshot module as well as the
individual member modules.
This is in preparation for a number of improvements and bug fixes in
both the snapshot creation code and implementations to address found
while trying to built the platform against ART prebuilts.
Bug: 151937654
Test: m nothing
Change-Id: Iac10f1200c0f283aa35402167eec8f9aeb65a38e
Added link type support in module creation code as cc_prebuilt_library
has to provide both shared and static libraries.
Had to add some calls to FirstUniquePaths() around the include dirs
settings in library_sdk_member as otherwise the shared variant contains
duplicate include dirs (presumably because it gets one set from its
dependency on the static variant and one set of its own). That
difference in include dirs causes problems in the generated
cc_prebuilt_library.
Test: m nothing
Bug: 142918168
Change-Id: Ie7f23fc2341c83c7814cc98e3970df4f5d4c8423
Test: m nothing
Test: Add
sdk {
name: "runtime-module-sdk",
native_shared_libs: [
"libc",
"libdl",
"libm",
"ld-android",
],
native_objects: [
"crtbegin_dynamic",
"crtbegin_static",
"crtend_android",
],
}
to bionic/apex/Android.bp. Then:
build/soong/scripts/build-aml-prebuilts.sh runtime-module-sdk
Take the generated runtime-module-sdk-current.zip and unzip into a
master-art tree without bionic/, edit the generated Android.bp to
extend cc_prebuilt_* modules with:
nocrt: true,
stl: "none",
system_shared_libs: [],
apex_available: ["//apex_available:anyapex"],
recovery_available: true,
vendor_available: true,
ramdisk_available: true,
Then "m com.android.art.debug". This passes Soong but fails in the
build step because more members are required.
Bug: 148934017
Change-Id: I2ab8f6aadb1440b325697cae4a8ed761c62d15d2
Previously, prebuilt had two ways to provide the src value, as a
pointer to an []string and using reflection. That meant that any code
that needed to check the src to use had to understand the two ways of
accessing it.
This change refactors the code to abstract the origin of the src values
being a supplier function. That insulates the callers from having to
know the details and makes it easy to add new suppliers in future.
Test: m nothing
Bug: 142918168
Change-Id: I5cc7517c46cce96924c9f34ba1b046b468f7684a
This was only being used to set the "stl" property for cc library sdk
member type and so that functionality was moved to AddPrebuiltModule()
and FinalizeModule was removed.
Required a few test changes to move the property to the correct
position in the generated module.
Bug: 142918168
Test: m nothing
Change-Id: If6400189833d4ff3285e7a7adf63a9b509e2a03b
This change ensures that the runtime dependencies between a
binary/shared library are correctly specified in the snapshot so that
the build can ensure that shared libraries are built before the targets
that use them.
It adds support for differentiating between references that are
required to refer to another sdk member (required) and those that may
refer to either an sdk member or a non-sdk member (optional). The
latter is used for shared library references as the libraries used by
an sdk member may be provided from outside the sdk. e.g. liblog is not
part of the ART module but is used by some members of the ART sdk.
Bug: 142935992
Test: m nothing
Change-Id: Ia8509ffe79b208c23beba1880fe9c8a92b732685
This change also added support for excluding properties from common
value extraction by using a struct tag of `sdk:"keep"` That was needed
to prevent the fields in SdkMemberPropertiesBase from having their
values cleared.
The purpose of this change is to make it easier to share functionality
across sdk member types.
Bug: 142935992
Test: m nothing
Change-Id: Ie5160a8f854056920e411801ca20721eab7c8578
Makes sure that the module snapshots do not rely on the white list
of apex available settings so that when those lists are removed it is
not necessary to update any snapshots.
Bug: 142935992
Test: m nothing
Change-Id: Iedcff7dfc2646a4da77258d16e06657dd2f411f9
Updates the member snapshot creation code to support multiple os types.
It basically sorts the variants by os type, then applies the code to
optimize the arch properties and then it optimizes the properties that
are common across architectures and extracts any properties that are
common across os types.
The java and cc member types needed to be modified to make the location
of the generated files within the snapshot os type dependent when there
is more than one os type. That was done by adding an OsPrefix() method
to the SdkMemberPropertiesBase which returns the os prefix to use when
there is > 1 os type and otherwise returns an empty string.
Added three tests, one for cc shared libraries, one for cc binary and
one for java header libraries.
Bug: 150451422
Test: m nothing
Change-Id: I08f5fbdd7852b06c9a9a2f1cfdc364338a3d5bac
As PRODUCT_ENFORCE_RRO_EXEMPTED_TARGETS is defined in make, define it in
soong accordingly
Bug: 150820813
Test: m
Change-Id: I309482b6ad439a7602127f68f2f7ffa856b9e192
Native modules within APEX should be linked with proper stub version
according to its min_sdk_version.
For example, when min_sdk_version is set to "29", libfoo in the apex
would be linked to libbar of version 29 from platform, even if it has
a newer version like 30.
Bug: 145796956
Test: m nothing (soong tests)
Change-Id: I4a0b2002587bc24b7deeb5d59b6eeba5e1db5b1f
Previously, while sdk tests would pass the sdk code would often fail
in androidmk processing. This change makes the tests more realistic
and will catch the errors earlier.
Bug: 142935992
Test: m nothing
Change-Id: Ifd0b2d7cf24e941c919f6b6e0beb2403a67d4308
Generalize the processing of arch specific properties to reduce
duplication in snapshot module creation and simplify addition of
support for handling multiple os types.
Supporting multiple os types with the current method for building
snapshot modules would require every affected module type to add
support for it. Rather than duplicate multiple os type handling code
across those module types this work generalizes the process cc modules
use for handling arch types as it can be used as a basis for handling
multiple os types. Migrating module types over to this new process
will insulate them from having to handle multiple os types.
OB
SdkMemberType changes:
* BuildSnapshot is deprecated in favour of the new AddPrebuiltModule()
method.
* Additional methods, CreateVariantPropertiesStruct() and
FinalizeModule() are added.
* A new interface SdkMemberProperties, is defined that handles
extracting information from the variant (prior to common value
optimization) and adding properties to a property set.
The sdk module type uses these new methods and types to delegate the
member type specific processing to the relevant member types while
handling the behavior that is common across all members types, e.g.
extracting common values across multiple architectures. A future change
will leverage this processing to add support for multiple os types.
This change also refactors the cc module processing to use the new
process.
Bug: 150451422
Test: m nothing
Change-Id: If6ab2498407b17f50391d062cd9afc01b5e01af4
Following how NDK also creates its own install path.
Bug: 142935992
Test: cc_sdk_test.go, java_sdk_test.go
Change-Id: I98a3656903f37f6d7c90e6cf609431b2461a6161
To build vndk-ext for product variants use `vndk.extends` property
with `product_specific: true` as for the vndk-ext for vendor
variants. For example:
cc_library {
name: "libvndk_ext_product",
product_specific: true,
vndk: {
enabled: true,
extends: "libvndk",
},
}
It will install the vndk-ext libs for product variants in
product/lib[64]/vndk/
Test: m nothing
Bug: 147778025
Change-Id: If1ee5be93c579abad302f44f18e6316f27e70019
This is an unchanged copy of build/make/tools/generate-notice-files.py
After this change, the make implementation of generate-notice-files.py
will change to take a required parameter for $(PRODUCT_OUT) and will
only include notices for files built under $(PRODUCT_OUT).
Because soong has the ability to walk dependency trees, the soong
version will likely change in the future to use that ability causing
both versions to move in different directions.
After those changes are complete, we can look into factoring out any
remaining shared logic.
Test: run manually and system image notices checked for changes
Change-Id: Id139a66503457615548b46e7996349ca0817e831
FirstUniquePaths is called on some long lists where the O(n^2)
behavior is problematic. Use a map-based implementation for
longer lists.
Test: TestFirstUniqueStrings
Change-Id: I7181aba869e5ccc0f99c2fa7b8f03839f06e4307
Adds a CommonOS variant for sdk that depends on the os specific
variants and is used to generate a single sdk for multiple OsTypes,
e.g. host linux and android.
At the minute the member types only support a single OsType but the
basic mechanism for managing the CommonOS variant and collating the
variants across all of them is there.
The only visible effect of this change is that the location of the
generated snapshot is changed, it is no longer os specific and instead
is in the same location irrespective of which os it is built for.
A lot of tests needed to be changed to specify "common_os" as the
variant type instead of the specific os type. As that is the same across
all tests it is hard coded in CheckSnapshot method.
Test: m nothing
Bug: 150451422
Change-Id: If36be39b06d6910453649f7c288c2d34f688b2f4
Remote execution and other tools can be confused by references to
build_number.txt without a dependency. Add an order-only dependency,
which maintains the current behavior.
Test: BUILD_NUMBER=1 && m aapt && aapt version # shows 1
BUILD_NUMBER=2 && m aapt && aapt version # shows 1
rm out/soong/.intermediates/frameworks/base/tools/aapt/aapt/linux_glibc_x86_64/aapt
BUILD_NUMBER=2 && m aapt && aapt version # shows 2
Change-Id: Icfa98d6840b1dc2e273ba29c33011635d1cf93b1
Collect the number of modules and variants and some basic statistics
on memory usage inside soong_build by writing out a proto that is
read back in by soong_ui.
Test: examine soong.log
Change-Id: I6926876377a4f6229cf41fdbf166ae03c885ea55
pathForInstall will allow code in the android package to get paths
to the install directory.
InstallPaths provides helpers for handling lists of install paths.
Test: m checkbuild
Change-Id: I058201b205bc8bc67f3c1f62952aaaf758c47fd8
As a second step to removing the go/android3p instructions to copy or
to link NOTICE to LICENSE, include LICENSE files in the notices, which
will allow deleting all of the copied/linked NOTICE files.
The change causes a few additions to the system image notice files.
Test: manually built and compared before and after notices
Change-Id: Ia7bc58e2eba7bed5e63934881b5298201a93bc3e
While it is invalid to mix //visibility:public with other rules in the
visibility property in a .bp file tt was possible, by overriding
defaults, to have //visibility:public mixed in with other rules in the
effective visibility rules. That caused problems when those effective
rules were used in an sdk snapshot.
This change replaces any set of rules that include //visibility:public
with just the //visibility:public rule. That simplifies those rules,
making them cheaper to process and ensures that the effective rules are
valid in the visibility property.
Adding test support required some refactoring of the
effectiveVisibilityRules(BaseModuleContext, ...) and underlying methods
to take a Config instead of BaseModuleContext as the tests do not have
access to BaseModuleContext.
Bug: 142935992
Test: m nothing - new tests failed without change, work with it
Add dex2oat to art-module-host-exports, build it and check the
generated Android.bp file in the snapshot to ensure the
visibility property for the dex2oat prebuilt does not mix
//visibility:public with other rules.
Change-Id: I08e7f0dcb40838d426fe88fedf69eae27b77473c
Move the NDK modules defined in app_test.go into cc/testing.go in
preparation for using sdk_version: "current" in more tests.
Test: all soong tests
Change-Id: I80bc31225fb4562fce42781219cefbbd6affae06
Robolectric tests compile against device modules but are installed
and run as host modules. Allow a module to override its install
OS.
Test: TestPathForModuleInstall
Change-Id: Icf37bb3d4cc1222a9b079602c6a5fdb8b51c86ed
Rename the two prefix-in-list funcs so that their usages are clearer.
Also find and replace all the code that essentially does either.
This introduces additional loops in some places, but I think the added
readability and simplicity outweighs the performance degradation, which
should be negligible anyway.
Test: m nothing
Test: TreeHugger
Change-Id: I37e2276ca0c815105ed0031f23c0b1264b480e4f
Bug: 149075752
Test: tapas com.android.conscrypt com.android.tethering arm64
Test: m out/target/product/generic_arm64/{,symbols/}apex/com.android.{tethering,conscrypt}/lib64/libc++.so
Test: Verified that unwinder was dynamically linked to tethering's
Test: libc++ and statically linked to conscrypt's.
Test: lunch flame-userdebug && m
Test: Verified that unwinder was dynamically linked to /system/lib64/libc++.so
Change-Id: I98eed7cb4316962b19b5c12e150c224c25d0e91d
With kernel support being removed for execute-only memory layouts,
remove support for XOM until there's kernel support again.
This allows us to gain the code-size improvements from
"-z noseparate-code".
Bug: 147300048
Test: Compiled binaries no longer marked XOM by default.
Change-Id: Ie84bdd2ca025e8b14867008291bf9ce143b5e999
This is to unify boot jars with system server jars:
PRODUCT_SYSTEM_SERVER_JARS and PRODUCT_UPDATABLE_SYSTEM_SERVER_JARS
do not overlap.
Test: aosp_walleye-userdebug boots
Exempt-From-Owner-Approval: cherry-pick.
Bug: 146363577
Change-Id: If001049a46f8e9d38921dabeedbd61e971ebfe73
Merged-In: If001049a46f8e9d38921dabeedbd61e971ebfe73
(cherry picked from commit ef4358e536)
Makes it clear that disabling a module is something that should be
avoided if possible.
Test: m soong_docs
Change-Id: Ief11e705f049edfd53b2af66bdf753f24d32aa71
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
libhidlbase is now being built without intermediate static libraries.
This requires a different neverallow exception for the
'enforce_vintf_manifest' variable.
Bug: N/A
Test: N/A
Change-Id: I5b7f7fc8eb4ac37d658e60a491c39baa5ac137f8
Adds an SdkMemberType implementation for java_system_modules. It
specifies that java_system_modules can be used with sdk as well as
module_exports, and also that the libs property should be included
as transitive members in the sdk.
It also adds support for treating appropriate tagged properties in
the snapshot prebuilts module as references to sdk members so that
they are correctly transformed when creating the versioned modules.
Bug: 142940300
Test: m nothing
Change-Id: Ic10b5a6d5b92b6018334fe876f06feaf79cc55e9
Allow an sdk member type to treat some of its dependencies as being
members of the sdk.
Needed for the java_system_modules type whose libs property are an
implementation detail of the system module and so should not be
explicitly listed in the sdk module but still have to be included in
the sdk snapshot.
Bug: 142940300
Test: m nothing
Change-Id: I90f37dae269ef64a6fe9debd0bbaf29a64dd74d8
Product variables structs are generated at runtime to contain only
the properties that apply to the current module. Defaults modules
always contained all product variable properties. Defaults modules
apply their properties to the target module using
proptools.PrependProperties, which prepends structs that have
matching types. Filtered property structs had a different type
and were dropped.
Even after adding filtering to the defaults product variable
properties, defaults modules may contain more property structs
than the target module they are applied to, so the product
variables struct for the defaults module could contain more
fields than the product variables struct for the target module.
Use proptools.PrependMatchingProperties when applying defaults
of product variables instead, which will apply matching properties
across types.
Test: defaults_test.go
Test: variable_test.go
Change-Id: I281bdefef92053457a3b7b65383493a4e7d999df
The zero value check was being done by using reflect.DeepEqual on a
field from the default product variables, but this results in
comparison against a random type when the product variables struct
for the module has been filtered down. Luckily this will always
fail false, which just removed and optimization but left the
behavior correct.
Use reflect.IsZero instead, which is both faster and correct.
Test: variable_test.go
Change-Id: Ieaaa590c2788ca39230e6695397e8ba8d1c6c103
Soong config variables come from Make where they might be capitalized,
but Blueprint didn't handle capitalized variables well. Add test
coverage for capitalized Soong config variables.
Bug: 148865218
Test: soong_config_module_test.go
Change-Id: I1e434e392d5ee660a221a0d3f959811c35e65865
Add a dependency on the Soong config module definition file in case
it wasn't called Android.bp.
Fixes: 148866376
Test: m checkbuild
Change-Id: Ib441881bcee52fd1dc3a8d1c5ae4f5f0b7efe3ce
This implements four modules (static/shared/header libraries, and
binaries) for vendor snapshot. These modules will override source
modules if BOARD_VNDK_VERSION != current.
Bug: 65377115
Test: 1) VNDK_SNAPSHOT_BUILD_ARTIFACTS=true m dist vndk vendor-snapshot
Test: 2) install snapshot under source tree
Test: 3) set BOARD_VNDK_VERSION and boot cuttlefish
Change-Id: I24ddb4c3aa6abeab60bbfd31bcbd8753e2592dc5
Vendor snapshot can be captured with "m dist vendor-snapshot". With
vendor snapshot and vndk snapshot, older version of /vendor and newer
version of /system will be able to be built together by setting
BOARD_VNDK_VERSION to past vendor's version.
Only vendor modules under AOSP are to be captured. In detail, modules
under following directories are ignored:
- device/
- vendor/
- hardware/, except for interfaces/, libhardware/, libhardware_legacy/,
and ril/
Test modules (cc_test, etc.) and sanitized modules are also ignored.
Bug: 65377115
Test: m dist vendor-snapshot
Change-Id: If7a2f6de7f36deee936930c0ccf7c47c4a0cebf6
This change fixes a bug that apex_available is not enforced for static
dependencies. For example, a module with 'apex_available:
["//apex_available:platform"]' was able to be statically linked to any
APEX. This was happening because the check was done on the modules that
are actually installed to an APEX. Static dependencies of the modules
were not counted as they are not installed to the APEX as files.
Fixing this bug by doing the check by traversing the tree in the method
checkApexAvailability.
This change includes a few number of related changes:
1) DepIsInSameApex implementation for cc.Module was changed as well.
Previuosly, it returned false only when the dependency is actually a
stub variant of a lib. Now, it returns false when the dependency has one
or more stub variants. To understand why, we need to recall that when
there is a dependency to a lib having stubs, we actually create two
dependencies: to the non-stub variant and to the stub variant during the
DepsMutator phase. And later in the build action generation phase, we
choose one of them depending on the context. Also recall that an APEX
variant is created only when DepIsInSameApex returns true. Given these,
with the previous implementatin of DepIsInSameApex, we did create apex
variants of the non-stub variant of the dependency, while not creating
the apex variant for the stub variant. This is not right; we needlessly
created the apex variant. The extra apex variant has caused no harm so
far, but since the apex_available check became more correct, it actually
breaks the build. To fix the issue, we stop creating the APEX variant
both for non-stub and stub variants.
2) platform variant is created regardless of the apex_available value.
This is required for the case when a library X that provides stub is in
an APEX A and is configured to be available only for A. In that case,
libs in other APEX can't use the stub library since the stub library is
mutated only for apex A. By creating the platform variant for the stub
library, it can be used from outside as the default dependency variation
is 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 fa89944c79)
Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
Previously, the java_sdk_library had special support for disabling the
stubs library when the build was configured to use prebuilts for sdks,
e.g. in an unbundled app build. That caused the prebuilt version of the
stubs library to be used instead. The disabling was done irrespective
of whether a prebuilt was available which prevents java_sdk_library
from being used in situations when prebuilts are not available, e.g.
when they have not been created yet.
This change moves the logic into tha java_sdk_library_import and
leverages the existing prebuilt/prefer mechanism to ensure that the
prebuilt version is used when required.
* Adds a ForcePrefer() method to Prebuilt to allow a module to forcibly
set the value of the prefer property.
* Sets prefer true on the java_sdk_library_import and the stubs modules
it creates when the prebuilt version should be used.
* Refactors PrebuiltJars for use by both java_sdk_library and
java_sdk_library_import as they both need to provide access to
prebuilts for previously released versions of the library.
* Removes disabling logic from java_sdk_library.
This will probably require some additional java_sdk_library_import
modules to be added to prebuilts/sdk/current/Android.bp.
Bug: 148080325
Test: m droid && TARGET_BUILD_APPS=Camera2 m
Change-Id: I0b5f751e82a2179a967ae64ca03dc9b9e7665c16
This is the 1st part of the CL. It adds support to enable compilation
of line coverage instrumented binaries. For more details please refer
to the design doc: go/android-line-coverage-doc
Bug: b/147604881
Test: Code works successfully on Taimen devices
Change-Id: I07745c1438b611041ed032dd4b7788cb50130845
Moves the struct to android/sdk.go and abstracts it behind a factory
method and interface. That allows it to be used outside the sdk
package.
This change is in preparation for adding support for module types that
have transitive sdk members.
Bug: 142940300
Test: m nothing
Change-Id: I71e5e0adf839b28a3a0952f82637637887f02688
This is preparation for enhancing the versioning tranformer to support
applying per property transformations. Specifically, to allow
properties to reference other libraries within the sdk.
Bug: 142940300
Test: m nothing
Change-Id: I99cdff4b407763ed395ff358d8110a63c6cf5589
In an AOSP aosp_blueline-userdebub build, OutputPath.String was
allocating 802MB of strings in filepath.Join to prepend the
out dir to each path. Allocate the joined string in PathForOutput
instead, which results in ~57MB of new allocations in PathForOutput
but no allocations in OutputPath.String.
Test: all soong tests
Change-Id: Id452e0c46a2aeda71bfac11a227bb6edb8e3523d
This is to support enabling scudo only for non-svelte configs.
Also, add exclude_static_libs to allow removing the jemalloc libs.
Bug: 137795072
Test: Verified that a svelte and non-svelte config can use this method
Test: to properly choose between scudo and jemalloc.
Change-Id: Iec6bfe159f8491138e93dde1d225a8c874c7ce31
This CL adds RBE support to javac, r8, and d8 rules which is only
enabled if respective environment variables are set.
Test: an aosp_crosshatch build with and without the new variables.
Change-Id: Ic82f3627944f6a5ee7b9f3228170c2709b1bfcb8
The value format that sdk_version (and min_sdk_version, etc.) can have
has consistently evolved and is quite complicated. Furthermore, with the
Mainline module effort, we are expected to have more sdk_versions like
'module-app-current', 'module-lib-current', etc.
The goal of this change is to abstract the various sdk versions, which
are currently represented in string and is parsed in various places,
into a type called sdkSpec, so that adding new sdk veresions becomes
easier than before.
The sdk_version string is now parsed in only one place 'SdkSpecFrom', in
which it is converted into the sdkSpec struct. The struct type provides
several methods that again converts sdkSpec into context-specific
information such as the effective version number, etc.
Bug: 146757305
Bug: 147879031
Test: m
Change-Id: I252f3706544f00ea71c61c23460f07561dd28ab0
Create a highmem pool based on the total RAM and the number of CPUs,
with an override via the NINJA_HIGHMEM_NUM_JOBS variable. Put
metalava into the highmem pool.
Ninja does not support nested pools, and when goma or RBE is enabled
the maximum ninja parallelism is set very high with local jobs in a
local pool. When both the local pool and highmem pool are enabled,
the total number of local jobs will be as high as the sum of the sizes
of the two pools. Keep the highmem pool limited to 1/16th of the
local pool when remote builds are enabled to try to minimize the
effect while still limiting highmem jobs.
Fixes: 142644983
Test: m nothing, examine pools
Test: m USE_GOMA=true nothing, examine pools
Change-Id: Id79f11f44948992960ac34ecf831dacbe21bd332
* changes:
Pass desired size proptools.FilterPropertyStructSharded
Do a better job removing tags from arch structs
Split the runtime arch property structs into 3
proptools.FilterPropertyStructSharded now takes a desired max size
of the name.
Fixes: 146234651
Test: all soong tests
Change-Id: Ifa10039e5f55a5d0f4a35172983d43f33af88e93
Remove more android struct tags from runtime created arch structs
to reduce the size of their names, which hit the 64kB limit in
runtime.StructOf if they are too long.
Bug: 146234651
Test: m checkbuild
Change-Id: I6362765275b93c8932eb0b1abbcb4be47031d9b1
Install to recovery/root/first_stage_ramdisk if BOARD_USES_RECOVERY_AS_BOOT,
otherwise ramdisk. In addition, append /system if not InstallInRoot().
Test: pass
Bug: 147347110
Change-Id: Ie5895ac61a3d5d85f5d958a27c7980d6c79d997e
Instead of creating a runtime generated struct type:
struct {
Arch struct {
Arm struct {
Armv7-a struct {
...
}
}
...
}
Multilib struct {
Lib32 struct {
...
}
...
}
Target struct {
Android struct {
...
}
...
}
}
Replace it with a top-level struct of empty interfaces:
type archPropRoot struct {
Arch, Multilib, Target interface{}
}
And then embed nil pointers to smaller structs inside it:
struct {
Arm struct {
Armv7-a struct {
...
}
}
...
}
This reduces the maximum number of times the archecture specific
properties are embedded in a runtime generated struct from 139
to 97, which makes it easier to avoid hitting the runtime generated
struct name size limit of 64kB.
Bug: 146234651
Test: all soong tests
Change-Id: I901c434ac9a1d99c74fc2370c5e6803b3682dc73
This is for use to add dependencies between specific module variants,
without getting the dependencies potentially duplicated as more
variants are created.
Moved genrule tool dependency registration to this phase, to avoid
potential splitting of its dependencies, and for consistency with the
same kind of dependency on dex2oat in https://r.android.com/1205730.
Test: m nothing
Bug: 145934348
Change-Id: I1f9e75354e359cef5f41d14e5016b0a67d7655d7
AAPT2 ignores assets in overlay resource inputs, so separate rules are
required to extract and merge assets from dependencies.
Test: app_test.go
Test: Added assets to Settings-core for testing
Test: Confirmed Settings.apk contains them with this change.
Fixes: 146655310
Change-Id: Iab8bc61b719541dae64f0e3502bc9cb45a353687
Now that ninja uses lstat so that we can get the mtime of the symlink
itself, it's safe to use a real input here rather than an order only
input. This matches how our other install rules work for host files.
Symlinks should be quick to recreate, so I'm not copying the logic to do
order-only dependencies for the device.
Bug: 128577186
Bug: 145278193
Bug: 135515543
Test: m out/target/product/walleye/apex/com.android.art.debug/javalib/arm/boot.art
rm out/soong/host/linux-x86/bin/dex2oatd64
m out/target/product/walleye/apex/com.android.art.debug/javalib/arm/boot.art
Change-Id: Ief5ec752ce0d0216aeecd8e904afc59f3f08ed7d
This means everything that goes into apexes need to be
explicitly labeled to be available for apex.
Whitelist the current offenders. This list should be
trimmed down.
Bug: 147364041
Test: m
Test: multiproduct_kati -only-soong
Exempt-From-Owner-Approval: cherry-pick from internal
Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
(cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
When both prebuilt and source versions of a module are present in the
build an implicit dependency is added from source -> prebuilt. This
change excludes that dependency from visibility enforcement as it
provides no value and would otherwise require an sdk snapshot to
rewrite the visibility of the generated prebuilt modules which would
be complicated.
The rewriting would include:
* Detecting //visibility:public and just passing that straight through.
* Detecting //visibility:private and replacing that with the location
of the source.
* Otherwise, adding the location of the source to the visibility
property.
This adds a general mechanism to allow any dependency to be excluded
from visibility enforcement by simply using a tag that implements
the ExcludeFromVisibilityEnforcementTag interface.
Bug: 142940300
Test: m nothing
Change-Id: I0668ff5aa798152d17faf3aac1bb8eff8d6350c3
Some pre arch mutators are hard coded into mutator.go and so could not
share code for registering those mutators between tests and runtime.
This change adds a new HardCodedPreArchMutators(RegisterMutatorFunc)
method to RegistrationContext which allows hard coded mutators to be
registered alongside other build components during init() and testing.
The method is treated as a noop on the InitRegistrationContext and
behaves just like the PreArchMutators(RegisterMutatorFunc) method on
the TestingContext.
Bug: 146540677
Test: m nothing
Change-Id: I6f8b1e2d54d9dc4e86f951ced61d1ee7b0fe4b2e
