This reverts commit 22ff0aaf51.
The workaround to support hidden API generation with prebuilts by
passing the full implementation jars through to the SDK snapshot is no
longer needed as the monolithic hidden API flag generation uses the
prebuilt flag files that are already part of the snapshot.
This change reverts that previous workaround.
Bug: 192868581
Test: - Update the prebuilts
DIST_DIR=$PWD/dist TARGET_BUILD_VARIANT=userdebug art/build/build-art-module.sh --skip-apex
packages/modules/ArtPrebuilt/update-art-module-prebuilts.py --local-dist=dist --skip-cls --skip-apex
- Build hidden API flags to make sure it does not fail
Change-Id: Idb3fde6f7dcb171677316d8794a4af91ede1f7e0
apexBundle was missing InitBazelModule for it to have bazel_module properties.
Test: soong unit test
Fixes: 193866723
Change-Id: I5fb38c8b2e8edaecef44162491d399c0223d3fb1
soong config variable modules allow specifying a non-existent property,
which results in an unhelpful error message when the module type is then
used.
Bug: 171232169
Test: go test soong tests
Change-Id: I6174c0d35a28952157ee925f51d615e2ee735f8a
The actual behavior of the method is slightly different from its text
right now. Update the text to describe the actual behavior.
Bug: 193228441
Test: m nothing (change is noop)
Change-Id: I755829af6aa1b3f95ac71f33d75751b94e71b54b
Bug: 188179858
Test: compare dexpreopt_config.zip files from
1. TARGET_BUILD_UNBUNDLED_IMAGE=true m dexpreopt_config_zip
2. m dexpreopt_config_zip
(note that m clean should run between steps)
Change-Id: I36a6e8b10b9922cc5522accaf90af1aa05049a86
Previously, a module reference in a path property would be parsed into
two parts, the module name and the optional output tag, which defaults
to an empty string if not specified. The output tag would be stored in
a sourceOrOutputDependencyTag which would then be used, along with the
module name to add a dependency on the module.
Later, when the paths were processed the same module reference would be
parsed into the same two parts again and the module name used to find a
matching Module by comparing it against the name returned by either
Module.Name(), ctx.OtherModuleName() or ModuleBase.BaseModuleName().
Once the module had been found then if it supported OutputFilesProducer
then the tag would be passed to its OutputFiles(tag) method. Otherwise,
it would fall back to treating it as SourceFilesProducer.
The problem with that is the module name retrieved from the module in
some way (either directly or through a context name) could be different
to that originally supplied when adding the dependency. e.g.
1. If the original dependency was added onto a source module but there
existed a suitable and preferred prebuilt module then the dependency
onto the source module would have been replaced by the prebuilt
module which has a different name.
2. If the path property included a fully qualified name that included
a qualifying path then it would not match the name retrieved from
the module which would not include the qualifying path.
This change circumvents that whole issue by adding the module name that
was originally used to add the dependency into the DependencyTag. Now
the DependencyTag uniquely identifies the original module/outputTag
pair parsed from the module reference. The pathDepsMutator guarantees
that they are unique as it dedups them before adding the dependencies.
It is possible that calling ExtractSource(s)Deps() would add some
duplicate but if they did they would be identical, i.e. the same
sourceOrOutputDependencyTag would be used to add a dependency onto the
exact same module. In that case it would not matter which of the
dependencies was found as it would still return the same module.
Bug: 193228441
Test: m nothing
Change-Id: I661514a2984818e5c26577411cede53eb57bcd02
A simple way to provide fine grained control over the use of a prebuilt
or source module via a Soong config variable.
Bug: 193523070
Test: m nothing
Change-Id: I47ae8ac04fa29156d2e87efd9e60ab995f50ea6d
This fixes a bug which was a misunderstanding of soong properties:
Soong's cflags pertain only to C and C++ language, whereas bazel's copts
pertain to all three languages. This change ensures that asflags are
added as specifically asflags, and the 'copts' for the static library
macro pertains only to C and C++ languages.
This requires a somewhat hacky workaround for asflags, however: Since
assembly sources also need includepath-related flags, this duplicates
these flags between copts and asflags. To reduce verbosity of
bp2build-generated targets, this also ensures that asflags are omitted
in cases where there are no assembly sources.
Test: Mixed build droid CI
Change-Id: Ic0babed1f90d6dc82e5788638681ce5b995043f8
A module reference to a fully qualified module in a path property looks
like:
//path:module
And with a tag:
//path:module{tag}
At the moment the checking is quite lax but some follow up changes will
make it much stricter.
Bug: 193228441
Test: m nothing
Change-Id: Ie42edcfa33ec66fda5d75b3df1da73f56f147afd
PathForModuleSrc calls validatePath in order to convert the supplied
path components into a single path. Unfortunately, that corrupts a
fully qualified module name. So, when given "//namespace:module" it
treats it as a path and replaces "//" with "/". That replacement is
done by a call to filepath.Join().
This change simply concatenates the path components together textually,
using the path separator, to avoid the corruption. That ensures that
a fully qualified module name is preserved and processed properly. If
the path components do not contain a module name then expandOneSrcPath
will call pathForModuleSrc which validates the path so it does not open
up a way to create an invalid path as the validation was unnecessary
anyway.
Bug: 193228441
Test: m nothing
Change-Id: I0bb66feac182b77ce96c8d5d5f17e28ea28d75ba
It reveals a number of issues:
* PathForModuleSrc corrupts the name during validation of path
components.
* SrcIsModule and SrcIsModuleWithTag do not handle fully qualified names
properly or detect invalid unqualified names.
* getPathsFromModuleDep does not handle fully qualified names.
Bug: 193228441
Test: m nothing
Change-Id: I583bc5e7f7df8a1b9cc32acefac3dbe43f49a27a
Previously, modules customized behavior around the handling of
sourceOrOutputDependencyTag by comparing them to android.SourceDepTag
and retrieving the module using something like this:
ctx.GetDirectDepWithTag(m, android.SourceDepTag)
The problem with that is it does not allow an output tag to be
specified and does not handle fully qualified names properly.
This adds the following:
* IsSourceDepTag and IsSourceDepTagWithOutputTag to check whether a
blueprint.DependencyTag is a sourceOrOutputDependencyTag. The latter
also checks that it has the correct output tag.
* GetModuleFromPathDep(ctx, moduleName, outputTag) as a replacement for
ctx.GetDirectDepWithTag(m, android.SourceDepTag).
Replaces usages of:
* t == SourceDepTag with IsSourceDepTagWithOutputTag(t, "")
* ctx.GetDirectDepWithTag(m, android.SourceDepTag) with
GetModuleFromPathDep(ctx, m, "")
It also deprecates the following:
* android.SourcDepTag - as a follow up change needs to modify the
sourceOrOutputDependencyTag will make this useless.
* ExpandSources, ExpandsSources - copies existing deprecated messages
from the implementation to the interface so that they can be seen
by users of that interface.
Bug: 193228441
Test: m nothing
Change-Id: I8c397232b8d7dc1f9702c04ad45ea7819d4631ae
License files must be captured with the snapshot modules. NoticeFiles
does not have the information provided by the `license` module.
Reading the `Effective_license_text`, snapshot includes the required
license files.
Bug: 190690041
Test: build
check the NOTICE files built from snapshots
Change-Id: I96c4579b4bef484cbb39fc06c707742a02a2b90b
Previously, hidden API processing could only be done by those
bootclasspath_fragment modules that either did not depend on any other
fragments (e.g. art-bootclasspath-fragment) or only depended on APIs
provided by other fragments (e.g. i18n-bootclasspath-fragment). That
meant that modules like com.android.os.statsd-bootclasspath-fragment
that depended on APIs provided by parts of the platform which are not
yet part of another bootclasspath_fragment could not perform hidden
API processing.
This change adds support for a bootclasspath_fragment to specify the
additional stubs needed to perform hidden API processing. It adds a new
additional_stubs property that can be used to specify the additional
stub libraries.
Most bootclasspath_fragments that need to use the property will need
access to the APIs provided by the android-non-updatable.* libraries.
Rather than have each fragment explicitly specify the correct module
for each scope it treats "android-non-updatable" as if it was a
java_sdk_library that can provide different jars for each scope.
Soong will handle mapping that to the correct android-non-updatable.*
module.
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-flags.csv \
out/soong/hiddenapi/hiddenapi-index.csv \
out/soong/hiddenapi/hiddenapi-stub-flags.txt \
out/soong/hiddenapi/hiddenapi-unsupported.csv
- make sure that this change does not change the contents.
m TARGET_BUILD_APPS=Calendar nothing
Change-Id: Ia8b79830ed0e6d42100de03d76b0c51b7f6c8ade
Previously whether prebuilt properties were customizable was dependent
on the order of calling various inits.
Test: go test soong tests
Bug: 191975220
Change-Id: Icaa1fe811a5f5fc4aa5fc9fa0ec0b90debe3d537
The property is used to allow non-updatable APEXes to use platform APIs
(e.g. symbols marked as "# platform-only").
Bug: 191637950
Test: m com.android.virt com.android.compos
Merged-In: Id2410b4e38a78ec2146a42298840954381a7c472
Change-Id: Id2410b4e38a78ec2146a42298840954381a7c472
(cherry picked from commit fb63625a7f)
Previously, an sdk snapshot could contain the following:
* A java_sdk_library_import module, e.g. "foo" which creates component
modules "foo.stubs", etc.
* A corresponding versioned module, e.g. "sdk_foo@current" which
created component modules "sdk_foo@current.stubs", etc.
* An internal (to the sdk snapshot) java_import for one of "foo"'s
components, e.g. "sdk_foo.stubs"
* A corresponding versioned module, e.g. "sdk_foo.stubs@current".
That causes a few problems:
1. The "foo.stubs" is duplicated.
2. The names of the components created by the versioned
java_sdk_library_import are invalid, as they append the component's
suffix to the version and not the name before the version.
The latter causes problems when building against prebuilts and fixing
that causes the generated snapshot to be invalid because it contains
duplicate definitions of the "sdk_foo.stubs@current" module. One
explicitly in the Android.bp file and one created by the
"sdk_foo@current" module.
Removing the duplicates from the snapshot causes errors as the name
generated by the snapshot for the component module, i.e.
"sdk_foo.stubs@current" does not match the name generated by the
"sdk_foo@current", i.e. "sdk_foo@current.stubs".
This change fixes them together.
Bug: 179354495
Test: m nothing
Merged-In: I515f235fe21755b5275af12366e96c24c94c0273
Change-Id: I515f235fe21755b5275af12366e96c24c94c0273
(cherry picked from commit a1aa7387f7)
Adds support for printing a PropertySet that has a property whose value
is an array of structs.
Bug: 179354495
Test: m nothing
m conscrypt-module-sdk
- check generated Android.bp file
Change-Id: I71be04188465610bcbea4d3c9a5e8204171a1eeb
Some codes assume that the first arch is the primary arch. But ndk/aml
arch order have been [arm, arm64, x86, x86_64]. This fixes the order to
workaround possible breakage while building ndk.
Bug: 187196593
Test: OUT_DIR=out build/soong/scripts/build-ndk-prebuilts.sh
Change-Id: I33164a7e7c64a23f2cc1860acb24a2584f4dffad
To support init_first_stage, install_in_root property is added to
cc_binary. The output is installed to {partition}, rather than
{partition}/{mount_point}/bin.
Bug: 187196593
Test: build init_first_stage
Change-Id: Ibc351645308676ed188f748972eb6312c9cbd64f
Previously, the prebuilt art-bootclasspath-fragment did not provide any
boot image files. That meant it was impossible to build any module that
requires access to those files from prebuilts, e.g. any module that
needs to be dexpreopt-ed.
This change enables that module to retrieve those files from the
prebuilt_apex.
Bug: 177892522
Bug: 189298093
Test: m nothing
m droid SOONG_CONFIG_art_module_source_build=false SKIP_BOOT_JARS_CHECK=true
- the previous command does not work but this change does fix one
of the issues reported.
Change-Id: I1d4d9545172d79282918130df6b9aa55471bffc1
Uses the apex relative path to the file as the identifier that is used
to obtain the path to the corresponding file extracted from the apex.
That is instead of a special constructed string id.
Bug: 177892522
Test: m nothing
Change-Id: I5dc77c8fb272bac289b8891d1eac801e541af1f5
Removes the special case in createDeapexerModuleIfNeeded for handling
java libraries and just get the Import and SdkLibraryImport module
types to implement RequiredFilesFromPrebuiltApex instead.
Bug: 177892522
Test: m nothing
Change-Id: I5cc341b5b4168b8eb196f72273a00d498de6856f
