This file contains the java APIs parsed by the 'dexdeps' tool within the gen_java_usedby_apex.sh.
Bug: 239084755
Fixes: 239084755
Test: presubmits
Change-Id: Ia271783a6be3ea3a343481306cde1aaba2166e88
The libcronet prebuilt JNI library doesn't exist for riscv64 yet.
Add exclude_* properties to apex arch-specific properties so that
the libcronet dependency can be excluded from the apex that contains
when the arch is riscv64 until it exists for riscv64.
Test: TestApexWithArch
Change-Id: Ic395a077824f0f60b90178530fbfae8a96b3782f
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
