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
Revert "Add ramdisk_available to init_first_stage's deps"
Revert submission 15071196-init_first_stage_soong
Reason for revert: fixes b/192248690
Reverted Changes:
I23cf4f975:Add ramdisk_available to init_first_stage's deps
Icd98c7e24:Add ramdisk_available to init_first_stage's deps
If9da9ba16:Add ramdisk_available to init_first_stage's deps
Ibc8668029:Add ramdisk_available to init_first_stage's deps
I3b4b8c475:Add ramdisk_available to init_first_stage's deps
I59cd149e0:Completely migrate init first stage to Soong
I36d789578:Add ramdisk_available to init_first_stage's deps
I2a0daa612:Add BUILD_USES_RECOVERY_AS_BOOT to soong config
Ic76c325ce:Directly create ramdisk dirs in ramdisk image rule...
I4c5374deb:Add BOARD_BUILD_SYSTEM_ROOT_IMAGE to config vars
I8aab5faf3:Add ramdisk_available to init_first_stage's deps
I9d5a10661:Add ramdisk_available to init_first_stage's deps
Iaa2edeb4a:Add ramdisk_available to init_first_stage's deps
I7cb582ca0:Update init_first_stage
I06091d15e:Add ramdisk_available to init_first_stage's deps
I8bdb8dda3:Add ramdisk_available to init_first_stage's deps
I7436b8dd1:Add ramdisk_available to init_first_stage's deps
I39693fd86:Add ramdisk_available to init_first_stage's deps
I0a9ba90f0:Add ramdisk_available to init_first_stage's deps
Ib66b4c4ea:Add ramdisk_available to init_first_stage's deps
I31ce63d23:Add ramdisk_available to init_first_stage's deps
Icb580f97c:Add ramdisk_available to init_first_stage's deps
I044a075b7:Add ramdisk_available to init_first_stage's deps
I33164a7e7:Fix ndk and aml arch order
Ib8d92904a:Add ramdisk_available to sysprop_library
Ibc3516453:Add install_in_root to cc_binary
Change-Id: I3f48a1bee726c7c2b38c9bdc501b2a32337eaab7
Revert "Add ramdisk_available to init_first_stage's deps"
Revert submission 15071196-init_first_stage_soong
Reason for revert: fixes b/192248690
Reverted Changes:
I23cf4f975:Add ramdisk_available to init_first_stage's deps
Icd98c7e24:Add ramdisk_available to init_first_stage's deps
If9da9ba16:Add ramdisk_available to init_first_stage's deps
Ibc8668029:Add ramdisk_available to init_first_stage's deps
I3b4b8c475:Add ramdisk_available to init_first_stage's deps
I59cd149e0:Completely migrate init first stage to Soong
I36d789578:Add ramdisk_available to init_first_stage's deps
I2a0daa612:Add BUILD_USES_RECOVERY_AS_BOOT to soong config
Ic76c325ce:Directly create ramdisk dirs in ramdisk image rule...
I4c5374deb:Add BOARD_BUILD_SYSTEM_ROOT_IMAGE to config vars
I8aab5faf3:Add ramdisk_available to init_first_stage's deps
I9d5a10661:Add ramdisk_available to init_first_stage's deps
Iaa2edeb4a:Add ramdisk_available to init_first_stage's deps
I7cb582ca0:Update init_first_stage
I06091d15e:Add ramdisk_available to init_first_stage's deps
I8bdb8dda3:Add ramdisk_available to init_first_stage's deps
I7436b8dd1:Add ramdisk_available to init_first_stage's deps
I39693fd86:Add ramdisk_available to init_first_stage's deps
I0a9ba90f0:Add ramdisk_available to init_first_stage's deps
Ib66b4c4ea:Add ramdisk_available to init_first_stage's deps
I31ce63d23:Add ramdisk_available to init_first_stage's deps
Icb580f97c:Add ramdisk_available to init_first_stage's deps
I044a075b7:Add ramdisk_available to init_first_stage's deps
I33164a7e7:Fix ndk and aml arch order
Ib8d92904a:Add ramdisk_available to sysprop_library
Ibc3516453:Add install_in_root to cc_binary
Change-Id: Iaccc4bada78e63fdae3249adfc668c0b30418758
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
Merged-In: Ia8b79830ed0e6d42100de03d76b0c51b7f6c8ade
Change-Id: Ia8b79830ed0e6d42100de03d76b0c51b7f6c8ade
(cherry picked from commit 5cca7c44e5)
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
Merged-In: Icaa1fe811a5f5fc4aa5fc9fa0ec0b90debe3d537
(cherry picked from commit 69d6413dd0)
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)
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)
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
Change-Id: I515f235fe21755b5275af12366e96c24c94c0273
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
Merged-In: 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
Merged-In: Ibc351645308676ed188f748972eb6312c9cbd64f
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
Merged-In: I5dc77c8fb272bac289b8891d1eac801e541af1f5
Change-Id: I5dc77c8fb272bac289b8891d1eac801e541af1f5
(cherry picked from commit b4bbf2ca10)
