Soong supports string properties, but they are overloaded, and can mean
one of three things:
* path reference
* module reference
* string literal
Bazel has different types: label and string attributes. Thus there needs
to be a way to categorize them correctly in bp2build.
This CL introduces a new function to be used on properties like
apex_key.private_key / apex_key.public_key, as well as
android_app.certificate / apex.certificate.
It is important to disambiguate the prop betenn a string literal
attribute or file/rule target label attribute, so this functions does
just that. The new attributes are then further handled by their
respective macros (apex_key, android_binary, apex).
Bug: 253557437
Fixes: 253557437
Test: presubmits, new tests
Change-Id: Id8111cdd60d3aabcae7d17fe9da84d0ee3966023
In Soong, decodeMultilib, used to get multilib to determine the dep variations, return "first" if defaultMultilib is set to "common". apex sets defaultMultilib to "common" which means equivalent compileMultilib in bp2build for apex should be "first" (See new Soong unit tests for more context).
This CL fixes bp2build for apex to be more correct.
Bug: 251559512
Test: go tests
Change-Id: Id1cb4407980fc1fab91822c81326f37fb4adfa0a
I49220cbec628f1508709741dc56b62aaac7786d9 attempted to allow
apexes to depend on native code whose min_sdk_version had been
increased to meet the minimum supported API level for a new
architecture. It wasn't quite right, as it assumed that the
primary architecture of the apex would be the newest, and
it applied to all dependencies, not just ones that were
specfiic to the new architecture. Move the checking into
cc.ShouldSupportSdkVersion, where it can be specific to an
individual architecture variant.
Bug: 250918230
Test: TestApexMinSdkVersion_MinApiForArch
Change-Id: I303cf485ba54b4c6bf63a9f9b49286ff9b2c9c83
* changes:
Move fuzzer's CollectAllSharedDependencies into GenerateAndroidBuildActions
Support AllowMissingDependencies in prebuilt_apex modules
Support AllowMissingDependencies for apex dependencies
Add AllowMissingDependencies support for prebuilt_etc module with no src property
Make OutputFileForModule work for AllowMissingDependencies
Fix panics when target arch is riscv64
Apexes for new architectures have to increase their minSdkVersion
to the minimum supported version for the architecture.
Bug: 250918230
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true nothing
Change-Id: I49220cbec628f1508709741dc56b62aaac7786d9
Use android.OutputFileForModule instead of cc.Module.OutputFile,
which will already handle the AllowMissingDependencies case.
Bug: 250918230
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true nothing
Change-Id: I605ae9afe06ac450adec1d2a856e529e45ed5cb5
Fix panics in api_level.go and apex.go when using riscv64 as the target
arch.
Bug: 250918230
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true nothing
Change-Id: I85c7685f3d14fa2dc7ffbcdea7f490feca304ef7
The certificate module is handled the same in Soong between android apps
and apexes, so share the bp2build code as well.
There are a few changes in this CL:
- If override_apex.certificate is unset, the generated apex also unsets
it. This prevents the generated apex from using the base apex's
certificate, which is most likely incorrect (e.g. google variant using
the cert for the aosp variant). Instead, rely on the default
certificate handling in the macro.
- If the certificate prop is a string, then it gets generated into
certificate_name in order to disambiguate. This behavior is identical
to android_app.
Test: added various unit tests.
Bug: 249089160
Fixes: 249089160
Change-Id: I99e18964ff546429a985d0f64dc21e2c69d35d9d
Also remove the soong hack that allowed us to build during the
transition
Bug: 243054261
Test: build + TH
Merged-In: I60bac1ec687f03a38f38240969a1c38a8e5bf92c
Change-Id: I60bac1ec687f03a38f38240969a1c38a8e5bf92c
Also remove the soong hack that allowed us to build during the
transition
Bug: 243054261
Test: build + TH
Change-Id: I60bac1ec687f03a38f38240969a1c38a8e5bf92c
Currently, DCLA is built in rapid. With new train build, DCLA will be
directly built in soong, just like a regular module, refer to
b/239679485. In old rapid built DCLA, native shared libs are placed the
following way inside apex:
/lib(64)?/foo.so/<sha256 foo.so>/foo.so
The sha256 hash is used to differentiate different libs. To ensure the
same lib placement in soong built DCLA, three changes are made:
(1) in apex.go, added an apex soong module property called
dynamic_common_lib_apex to indicate if this apex is a DCLA
(2) in builder.go, update apexRule to call into run_apexer binary
instead of apexer binary. run_apexer binary is a wrapper of apexer
binary. If it is DCLA, the wrapper binary will place the native
shared libs in desired location and update canned_fs_config accordingly.
TEST: manuualy added this field to adbd. Local build by banchan
and then inspect the payload image contensts. All libs are proprely
placed.
BUG: 241096765
Change-Id: I2a5e7ea75a6e9a7af1932ff7dccb9dc3a3785db9
* Add ApexCqueryInfo to obtain apex artifacts used by the makefile
generator and downstream modules
* Refactor code common to GenerateAndroidBuildActions and ProcessBazelQueryResponse
* Implement android.MixedBuildBuildable for modules
* Enable mixed build for apex modules with payload_type:"image"
The first take 6a2b7c40b was setting compressed APEX suffix incorrectly, and
was reverted in 8a3c91494.
Fixes: 239925080 239695521 232085015
Test: treehugger
Change-Id: I1720f8db3c7cc773183d25a815d9b7eeaf7c73ad
Previously, the platform_compat_config modules needed to be explicitly
listed in the sdk snapshot and the apex. This change will automatically
export them to the sdk snapshot when the apex is listed in its apexes
property.
Bug: 232401814
Test: m tethering-module-sdk
# Before this change the generated snapshot did not contain the
# platform_compat_config, after this change it did.
m art-module-sdk
# As that explicitly specifies the platform_compat_config in its
# compat_configs property this change has no effect.
Change-Id: Ia854b9a52db2b1619fca41a387ce98d7f9f9efe9
* Add ApexCqueryInfo to obtain apex artifacts used by the makefile
generator and downstream modules
* Refactor code common to GenerateAndroidBuildActions and ProcessBazelQueryResponse
* Implement android.MixedBuildBuildable for modules
* Enable mixed build for apex modules with payload_type:"image"
Bug: 232085015
Test: treehugger
Change-Id: I9f1e03e5e7a5b5dde35a5db10c253069543ac973
Specifying an apex in the apexes propety will cause all the
*classpath_fragments that are contents of the APEX to be automatically
added as members of the sdk and appear in the snapshot.
The purpose of this change is to dedup the APEX and sdk definitions and
try and avoid some of the issues that we have been finding while
attempting to build against the prebuilts.
Two tests, one each for bootclasspath_fragment and
systemserverclasspath_fragment, have been refactored to compare the
output when adding the *fragment to the sdk directly of via the APEX.
That ensures switching to use the APEX will not change the sdk snapshot
unless it was previously missing a *fragment.
There was also a slight difference in where the hidden API flags were
copied from. That should have no impact on the output as the flags are
identical.
The sdk snapshot generation needed some tweaks to avoid generating a
prebuilt for the APEX.
Bug: 232401814
Test: m nothing
Change-Id: I7aaf16a3a0ab4bebf97765d1484215cc008dc4b8
The module availability to Bluetooth is currently hard-coded in apex.go.
We are in the process of cleaning the apex.go by adding the availability
in each required module
Test: Build + TH + boot phone & use bluetooth
Bug: 216433795
Change-Id: I883a12f89a6d7eb43778e04ac50d6af38dd97116
