The image apex does not need all the files that make up a flattened
apex.
Bug: 254205429
Test: go tests
Change-Id: Iff05f2d01f11397bc9e9bf31868112575268969b
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
There are no riscv64 apex prebuilts, which breaks the build when
provenance_metadata singelton tries to run a tool on all the input
apexes that don't exist. Hack it to provide the arm64 apex for now
if no riscv64 apex is specified, which will allow the build to pass.
Test: lunch aosp_riscv64-userdebug && m droid
Change-Id: Ic39936539803615ea4b7f817daf7b59ab7c40e7e
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
This fixes a bug that only the primary output of an appSet is installed
when the appSet is part of a flattened APEX.
Bug: 247072627
Test: m GoogleExtServices on a device using flattened APEX.
system/apex/com.android.extservices.gms/priv-app/GoogleExtServices@TM
has these apks:
GoogleExtServices.apk GoogleExtServices-arm64_v8a.apk
GoogleExtServices-hdpi.apk GoogleExtServices-ldpi.apk
GoogleExtServices-mdpi.apk GoogleExtServices-tvdpi.apk
GoogleExtServices-xhdpi.apk GoogleExtServices-xxhdpi.apk
GoogleExtServices-xxxhdpi.apk
(before the fix, there only was GoogleExtServices.apk)
Change-Id: Icbc4dd002f856a3f751badec781ad132c423ac9b
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
(and remove unused keyName field.)
The private_key and public_key props of an apex_key can point to either
a module or a string. If it's a module, then respect it. If it's a
string, there's additional product variable lookup to find the apex_key
files in product_vars's DefaultAppCertificate parent dir.
This is similar to android_app_certificate.
Test: presubmits
Change-Id: Ib258da14cb0c2df8b5f817fcbc46afebcf225db8
* 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
Arch-specfic prebuilt_apex modules may be missing prebuilts for new
architectures. Mark the module as missing dependencies and allow
build analysis to continue when AllowMissingDependencies is set.
Bug: 250918230
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true nothing
Change-Id: I79f0c20a0c9443fe443f9ed9bc846aa649f6b6a6
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
This change fixes a bug that base APK of an AppSet is not put into the
APEX.
Bug: 236299724
Test: m nothing
Change-Id: I1010ec66d8551fcc1e2d9119be7ecdba22186607
This allows apex_set's set config to use other soong modules as a dependency
Bug:249169376
Change-Id: I8da20c6f474328d63d9aa3811f94e3e04b89ea4c
Test: Added a test case to check soong module assignment to the set field of an apks_set rule
