Convert orderfileDepsMutator and orderfileMutator to a TransitionMutator
as a step towards variants-on-demand.
Bug: 319288033
Test: orderfile_test.go
Change-Id: I27df65b7264a5b059a900e7ea04c18dfb2787a84
Convert ltoDepsMutator and ltoMutator to a TransitionMutator as a
step towards variants-on-demand.
Bug: 319288033
Test: lto_test.go
Change-Id: I2c9af73fd526adf58ff626831ababea466338205
For prebuilts, java.dexpreopt gets called twice
1. in the context of the top-level prebuilt apex
2. in the context of the java_library shim
Only the artifacts of (1) get installed. The artifacts generated by 2)
are unused. However the args used to generate the artifacts of (1) are
incorrect. It uses moduleName(ctx) to do special-handling of apex system
server jars. This special-handling does not happen in (1), so although
dexpreopt artficats get generated, they get generated with the wrong
args.
To fix this, add an additional parameter in java.dexpreopt to pass the
libraryName explicitly.
Details
- Delete moduleName function. This was used to determine the java
library name, which is no longer safe
- Add a libraryName parameter to java.dexpreopt
- Most module types will use j.Name() as libraryName
- prebuilt_apex and apex_set will iterate over its `contents` and use
each element as libraryName when invoking java.dexpreopt
With the correct args passed from (1), we can drop j.dexpreopt from (2)
completely. Dropping (2) also breaks profile guided dexpreopt tests.
These currently operate on (2). They will be moved to (1) in the next CL
of this stack.
Test: presubmits
Test: lunch cf_x86_64_auto-trunk_staging-userdebug && m nothing (this
was a postsubmit failure with aosp/2923733)
Test: art_standalone_dexpreopt_tests on next https://android-build.corp.google.com/builds/abtd/run/L86000030001579256
Test: art-gtest on git_master-art-host https://android-build.corp.google.com/builds/abtd/run/L07800030001550262
Bug: 308790457
Bug: 322255144
Change-Id: I8eb604c82f1fa5289d3cd1a20084d56e4d7485e3
Setting the RELEASE_USE_RESOURCE_PROCESSOR_BY_DEFAULT build flag will
change the default for use_resource_processor from false to true.
Bug: 294256649
Test: builds
Change-Id: If643bf8db9e2e039200f63f4aac226ed5b44d9e0
I wrote another tool filter and augment the proto files, but these proto
files need to have a python library for that tool.
Test: m filter_teams && out/host/linux-x86/bin/filter_teams --filter_teams
Change-Id: I6b259ddda2b6c09d55a9c6d445b96e5b77741f09
This provider contains information about the contents of an apex and is
set during the post deps phase of top-level source and prebuilt apexes.
java.dexpreoptDisabled needs to distinguish between platform and apex
variants of a library to prevent creating duplicate ninja rules. It does
so by looking at ApexInfoProvider. This provider gets set on the ctx of
the java_library being dexpreopted.
In case of prebuilts, these rules are being moved to the top-level
prebuilt apexes. Move ApexInfoBundleProvider from apex to android so
that java.dexpreoptDisabled can consume this provider without running
into a golang circular dependency. (java.dexpreoptDisabled will use this
provider in the next CL of this stack).
Test: go build ./android ./apex
Change-Id: I665abd9d0591eeb17b273cc822beb20690e6af09
Aconfig file dependencies are module-independent, and properly part of
ModuleBase.
Bug: b/308625757
Test: manual
Change-Id: I38c5907d1671cc69bb198345201316ae781fdc9f
Convert coverageMutator to a TransitionMutator as a step towards
variants-on-demand.
Bug: 319288033
Test: coverage_test.go
Test: treehugger coverage builds
Change-Id: Ic50c0040dea8b42c36b5d784221daa00b7b0d379
Converting coverageMutator to a TransitionMutator requires adding
the ctx.Device() and ctx.DeviceConfig() methods.
Bug: 319288033
Test: builds
Change-Id: I697b48eb89bc23800d2d3c62d68358769f0d1075
Split the context methods that are useful on anything visiting a
module that has arch variants into a separate ArchMutatorContext
for reuse by TranstitionMutators.
Bug: 319288033
Test: builds
Change-Id: Ifdc21983c6c79f22965a49f169812a8cc3ad975b
For chromebooks, we need a new build variant whose target arch is
goldmont, but without SHA and XSAVES support (b/314243939#comment21)
Bug: 314243939
Test: Build an image with TARGET_ARCH_VARIANT:=goldmont-without-sha-xsaves
Change-Id: If73660b515b443d5c138ca367fa3d1c6f18485b5
(This was missed in aosp/2876756, which copied only the bcp jars)
This hardcoded location is used by dex2oat to compile the dexpreopt
artifacts. The copy rules are currently generated by java_(sdk)_library
for source builds, and their prebuilt counterparts in prebuilt builds.
After this change, the copy rule will be bifurcated between source and
prebuilt builds
1. For source builds, it will come from java_(sdk)_library
2. For prebuilt builds, it will come from the top-level prebuilt apex.
Since there can be multiple prebuilt apexes in trunk stable,
HideFromMake will be used to determine which deapexed jar to copy.
The bifurfaction is expected to be temporary. It is needed for now since
the `apex_contributions` which will be used for source vs prebuilt
selection have not been populated completely.
Test: Added a unit test
Test: Presubmits
Test: git_master-art-host:
art-gtest (https://android-build.corp.google.com/builds/abtd/run/L40800030001459791)
Test: git_main:art_standalone_tests
(https://android-build.corp.google.com/builds/abtd/run/L09000030001463855)
Bug: 308790457
Change-Id: I3105d3b3a7e5c41cb601d07806f4ea483a61b50a
hiddenAPIFlagFileCategory used to contain function pointers, and is
used in a provider. Providers must be serializable for incremental
soong support, so the function pointers must be removed.
Refactor hiddenAPIFlagFileCategory into a simple int.
Bug: 322069292
Test: m nothing --no-skip-soong-tests
Change-Id: I2bd50fa1b59979f30869b405314cbef16ee345f1
Given that WITHOUT_CHECK_API=true is incompatible with from-text stub
build, this change makes the module raise an error when the two
conflicting configurations are set.
This change also modifies the checkapi error message, that
DISABLE_STUB_VALIDATION does not bypass checkapi.
Test: m nothing --no-skip-soong-tests && WITHOUT_CHECK_API=true m nothing
Bug: 322060779
Change-Id: I597309baa8fcfbefa05863c7b392bfb8b6774cea
Although vendor modules can be built bundled, they are technially not
part of the "platform", as it cannot access platform libraries (system
partition) directly.
They can only link to a restricted set of platform libraries (LLNDK),
and access restricted set of APIs.
We used to derive the LLNDK API level from the VNDK version. However
after VNDK deprecation, there is no "VNDK version" anymore.
Instead we would just derive the value from platform SDK version:
* If building an in-development build, build vendor modules against the
in-development "current" API level.
* If building a REL / Final build, vendor should target the latest
stable API.
Bug: 320423828
Test: go test
Test: presubmit
Test: build and boot
Change-Id: I2c5ef6530e9046b2dcc282bc1f020d8a505eab15
No-one ever fixes unused-* or deprecated-* warnings in external/ (nor should they!).
-Wno-deprecated-enum-enum-conversion should probably have been added
next to -Wno-deprecated-anon-enum-enum-conversion when it was added,
since it's a major spam contributor, and equally unlikely that anyone
will clean them up.
-Wno-deprecated-dynamic-exception-spec is a weird special case because
it should be irrelevant after our next libc++ update, but in the
meantime -- because libc++ is used everywhere -- this is a massive spam
contributor that no-one on Android cares about because we don't use
exceptions (and the people seeing this can't fix libc++ anyway).
Test: local clean builds
Change-Id: I098202337e9e5026c4c5215dbf5a2abf1fbbdca8
In order to prepare generating "runtime" stubs in droidstubs, this
change performs some cleanups, which are:
- Modify droidstubs providers methods to take a StubsType enum as an
input, in order to remove exportable-specific providers. The methods
are also modifed to return an error when the artifact is not provided
for the input StubsType.
- Wrap droidstubs artifact to a struct. This removes artifacts common to
all stubs types from being written out as a individual module property
(e.g. exportableAnnotationsZip -> exportableArtifacts.annotationsZip)
Test: m nothing --no-skip-soong-tests
Bug: 319162970
Change-Id: I6d6c57c5417ca71eab5ddda7981b71fd84fa6ee1
The previous patch was insufficient. Craig Topper explains:
-fno-vectorize only disables the loop vectorizer
-fno-slp-vectorize only disables the SLP vectorizer
The backend can also use vector instructions for memcpy/memset or
combining multiple scalar loads and/or stores. That is independent
of -fno-vectorize.
-mllvm -vector-bits-min=0 will disable any use of fixed vectors. And
will make attribute(vector_size) get scalarized.
-mno-implicit-float will disable both vectorizers and
prevent the backend for using vectors for memcpy/memset
oor multiple scalar loads/stores. It will not affect
attribute(vector_size). -mno-implicit-float also prevents scalar
floating point instructions from being used for anything that didn’t
use float/double/_Float16/etc. type in source, but I don’t think that
happens on RISC-V today. 32-bit X86 can use a 64-bit x87 FP load as an
atomic load for uint64_t, for example. Basically -mno-implicit-float
is supposed to prevent the compiler from using FP or vectors when the
source doesn’t explicitly use FP or vectors.
So -mno-implicit-float was what we were actually looking for here. I've
done a clean build with this change, and see only the expected
(hand-written assembler) vector code in bionic, and the ART
ClassLinker::LoadClass() issue is gone too. As far as I can tell, the
remaining vector code is all deliberate in that sense.
We may still end up back here again, to change "gcv" to "gc", but that
still requires some code changes just to build, and still makes it less
obvious that this is just a temporary workaround for a qemu bug
(specifically https://gitlab.com/qemu-project/qemu/-/issues/1976).
Bug: http://b/320416684
Test: objdump
Change-Id: Ibd104e4289d6d1aaf441efa0440fedc90e3da29a
The different roles of stubs (e.g. dependency to java modules,
hiddenapi, dist to sdk snapshot) are now split to different set of stubs
(everything, exportable and eventually runtime), while a single set of
stubs are responsible for all roles for the prebuilt stubs. Thus, the
stubs from source are depending different stubs tag (e.g.
everythingStubsTag, exportableStubsTag), while the prebuilt stubs
utilize stubsTag. Given that this tag is only used for the prebuilt
stubs, it can be renamed to `stubsTag`.
Test: m nothing --no-skip-soong-tests
Bug: 319162970
Change-Id: Iacdf434fab6a403482fd2f1de24e6f260ad80756
