Partner worksapces contain two versions of mainline prebuilts - BigAndroid
and Go. These two prebuilts export dexpreopt'd system server artifacts
to be installed in system image. Since the install paths are same, we
run into duplicate installation rules issue unless one of them is
hidden.
This hiding was previously done by creating a dependendency between
source aosp apex to BA and Go google prebuilts. However, this
implementaion had the unfortunate side effect on the packaging name of
the Google mainline prebuilts - the name becomes the aosp apex name.
Instead of creating the dependency to aosp apex, this CL hides all
mainline apex_set(s) if it has not been flagged using
RELEASE_APEX_CONTRIBUTIONS_*. Since there are some non mainline apex
prebuilts, apex_name will be used to determine whether the prebuilt is a
mainline module.
Test: m nothing --no-skip-soong-tests
Test: In partner workspaces, downloaded the CLs in b/355682304#comment7
Test: m out/target/product/generic/obj/PACKAGING/system_intermediates/file_list.txt
verified that aosp apexes are not installed, but mainline prebuilts are
installed
Test: unset RELEASE_APEX_CONTRIBUTIONS_ADSERVICES to build from source
Test: m out/target/product/generic/obj/PACKAGING/system_intermediates/file_list.txt
verified that aosp adservices is installed, and adservices prebuilt is
**not* installed.
Bug: 355682304
Change-Id: Idacb65313553bdea5c0593976694de478034229e
https://r.android.com/2901309 added support for handling installation
rules for multiple prebuilts. One of the implementation details there
was to change LOCAL_MODULE name to the source apex name in the generated
.mk files.
This causes issues in partner builds where the google singed apex
com.google.android.foo gets renamed to com.android.foo in
out/soong/Android-$PRODUCT.mk. If the partner builds does not include
the aosp apex in its PRODUCT_PACAKGES, then the google signed apex gets
elided from packaging.
This CL undoes that change. After this CL, the name of the module as it
appears in Android.bp will match the LOCAL_MODULE name emitted for
product packaging.
Test: in build/soong, go test ./apex
Bug: 355682304
Change-Id: Icadbb75609174cff5326f52baf7d53e901f9f1c0
Platform variants of module sdk libraries were marked as uninstallable
originally in https://r.android.com/1974259. This special case is no
longer necesssary - android.MutateApexTransition will call
MakeUninstallable on the platform variant on both the source and
prebuilt soong modules when the following conditions are met
- //apex_available:platform is not listed in apex_available (explicitly
or via the default implicit)
- the soong module is included in an apex that exists in the tree
(listed in native_shared_libs)
Since MakeUninstallable is set by apex specific mutators, the relevant
unit test has been moved to the apex package. The Android.bp of the test
has also been extended with an apex that includes the shared library.
Test: m nothing --no-skip-soong-tests
Test: no diff in out/soong/Android-$product.mk
Test: added prebuilt_libdexfile to art's apex_contributions locally, no
diff in out/soong/Android-$product.mk
Bug: 220898484
Change-Id: I43a324882d486451bb921028853508d7ec3d76bf
Since VNDK is gone now, the property has no meaning. Will remove the
property after removing all the references(there're no-op for now).
Bug: 350644693
Test: m
Change-Id: I85637ede5534a3b993ac12656e4aba8d945fec14
Updatable apexes should not min_sdk_version to `current`, since
`current` can have different meanings based on when plaform finalization
happens.
Test: m nothing --no-skip-soong-tests
Bug: 221087384
Change-Id: I04aaa4a331027b7afbf6ccdb9cbf3ae670827c9f
Remove test_per_src, it never worked well and is incompatible
with all of the test infrastructure. Uses in the platform have
been removed, generally by replacing them with individual cc_test
modules.
Test: builds
Flag: TEST_ONLY
Change-Id: I257c035da35ca8358ae9423b46453878f54efeb1
This change adds a unit test for https://r.android.com/3146677
Test: m nothing --no-skip-soong-tests
Bug: 339267677
Change-Id: I48e1c2681aaa153b32b209f05a93c501af5d1bac
Followup to the fix in https://r.android.com/3137737. This adds a unit
test to check the permission xml file contents of sdk library. This file
contains the on-device location of the sdk implementation library.
override/overridden apexes are installed in the same location, so the
on-device sdklibrary path should remain consistent in the xml files of
the override and overridden apexes.
Test: go test ./apex
Bug: 346486531
Change-Id: I61adbf94bdfce8aa89de89cc90b6f564f2f7417f
As VNDK definition is fully removed from Android.bp, VNDK related code
can be removed from Soong. This change removes VNDK related code except
VNDK prebuilt which is required to build former versions of VNDK APEX
with prebuilts.
Bug: 330100430
Test: AOSP CF build succeeded
Ignore-AOSP-First: Resolve Conflict
Change-Id: Id9c8993343221c8464c97296bde0ff40b14b9b0b
Since overrides are implemented as variants of the source module, the
override module should not be replaced with prebuilts of the source
module even when the prebuilt is preferred.
Test: go test ./apex
Change-Id: I26e97f700276e7beaf6d1bd61b164f11d57a5e09
* changes:
Revert^2 "Refactor how jni_libs dependencies are added"
Revert^2 "Add make java.dependencyTag installable or not"
Revert "Revert "APK-in-APEX should set use_embedded_native_libs:..."
Revert^2 "Install jni symlinks in Soong"
Revert submission 3094658-revert-3088867-QEHDREAABY
Reason for revert: not a regression
Reverted changes: /q/submissionid:3094658-revert-3088867-QEHDREAABY
Change-Id: Ie1e4a196f181643a3e64e573b132d52d7455461b
The use case for this are go apexes which are only installed in T and
above, even though the base AOSP apexes might be installable on < T
devices.
If provided, the overridden min_sdk_version will be
1. Used as the `min_sdk_version` in the manifest file of the
top-level override apex binary
2. Used to build the transitive closure of its dependency with that
min_sdk_version, i.e. with a different apex variant.
(2) requires some special handling. At ToT, the outgoing transition
value is the base apex name (e.g. com.android.foo). Since
min_sdk_version of the overridding apex can be different than the
overridden apex, the base apex name is no longer sufficient. Instead,
transition to the name of the overriding apex com.mycompany.android.foo.
If deduping is possible, transitive deps will get deduped to
`apex_<min_sdk_version>` later.
Test: added a unit test
Test: in internal, modified min_sdk_version of com.google.android.go.art
locally, built BA and Go apexes, and used `aapt2 dump badging` to verify
that BA has minSdkVersion of 31 and Go has minSdkVersion of 33
Bug: 295311875
Change-Id: Ifbe123d1517fccbc0c058042b8a6eeb3609b6787
* changes:
Revert "Install jni symlinks in Soong"
Revert "APK-in-APEX should set use_embedded_native_libs: true"
Revert "Add make java.dependencyTag installable or not"
Revert "Refactor how jni_libs dependencies are added"
Revert submission 3088867
Reason for revert: On cf_auto build, we are seeing a symlink of jni lib pointing to lib64/libcarservicejni.so, which does not exist on the device.
Reverted changes: /q/submissionid:3088867
Bug: b/341335305
Change-Id: I3064caef0cb55d1594951835a1173c667f58e607
So far, we automatically have embedded JNI libs for APKs in APEX, even
if use_embedded_native_libs was not set or set to false.
With this change, such APKs should explicitly set the property.
This is in preparation for an upcoming change for using different
dependency tags to JNI deps depending on whether they are embedded (thus
no install is needed), or not (thus installation to the partition is
needed).
shouldEmbedJni function now doesn't make use of the ApexInfoProvider
which is not available during deps mutator.
Bug: N/A
Test: m
Change-Id: I836171aacba19dbfa0e09f16a773ae498c56d60b
platform-bootclasspath constructs the monotlithic hiddenapi flags by
looking at PRODUCT_BOOT_JARS which are not included in another
bootclasspath fragment. PRODUCT_BOOT_JARS is a product specific
property, and non java devices like minidroid have an empty value for
this. For such devices, the monolithic flag generation runs into an
error because there are no jars to run this on.
This CL disables the generation of monolithic specific hiddenapi flags
when there are no monolithic boot jars in the build.
Bug: 338363444
Test: lunch aosp_cf_x86_64_minidroid-trunk_staging-userdebug && mmma
frameworks/base
Change-Id: I093690786bcf85b2aa6f01d0c689fc2a35861b5c
Currently, you can't have two prebuilt_etcs in one apex with the same
file name, because apexes emit make modules for all the files in the
apex, and the module name for the prebuilt_etc's make representation
is based on the base filename of the installed file. We can change it to
be qualified based on the full relative path of the outputfile so that
you don't hit the conflicts as much.
Fixes: 340207931
Test: Presubmits
Change-Id: I7836fd4661fcaafd91901eba7e0b89506946c3e2
This change modifies the build actions of java_sdk_library module type
so that it does not perform any compilation actions (i.e. does not
create the top level java_sdk_library jar file). Instead, it delegates
the build actions the top level jar file was performing to the
dynamically created ".impl"-suffixed java library module. The build
actions that are delegated to the impl library module include hiddenapi
processing, dexing, and dexpreopt.
This change relands https://r.android.com/3035972. Implementation
changes from the original change:
- "all_apex_contributions" is added as a dependecy to the implementation
library modules where the parent sdk_library module has a prebuilt
equivalent. This allows the source apex variant to be hidden from make
when the prebuilt is active.
Test: patch in internal main, lunch barbet-ap2a-userdebug && m nothing
Test: m nothing --no-skip-soong-tests
Bug: 332785297
Change-Id: I017938e5567aef82e428e7ceb557d9c9090e0257
Revert submission 3070882-sdk_lib_remove_compilation
Reason for revert: Potential culprit for build breakage of barbet-ap2a-userdebug in git_main
Reverted changes: /q/submissionid:3070882-sdk_lib_remove_compilation
Change-Id: I5135760e13e0152480c68fe91a3c88564e9bc7cb
This change modifies the build actions of java_sdk_library module type
so that it does not perform any compilation actions (i.e. does not
create the top level java_sdk_library jar file). Instead, it delegates
the build actions the top level jar file was performing to the
dynamically created ".impl"-suffixed java library module. The build
actions that are delegated to the impl library module include hiddenapi
processing, dexing, and dexpreopt.
Test: m nothing --no-skip-soong-tests
Bug: 332785297
Change-Id: I7534f9eaacf6d9f72fbf8d540b1e26af84106c20
This allows using select statements with it.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I6f3efaaa3d82505e38a91ee4ba0e18e404360191
Merged-In: If355d24506e3f117d27b21442a6c02bca3402dc7
Currently VNDK contains some logic for LLNDK libraries as they are
treated in a similar way with VNDK. However, those logics should stay from
VNDK deprecation. To keep the logic, this change moves LLNDK related
logic into llndk_library.
Bug: 330100430
Test: Soong tests passed
Test: llndk.libraries.txt did not change from CF build
Change-Id: I1d02a3c2a398f1b1060b4f2bdd23af32310503bb
Use the `WriteFileRule` to write the permissions file for shared
libraries instead of generating a custom bash rule.
Test: TH
Change-Id: I904cf0742bfec46ed45ec7801bb9bd3dc3047185
Existing snapshot code will no longer work from VNDK deprecation, but it
can give confusion to users if we keep code for the snapshot - and it
adds complexity on existing code while it is not in use. This change
removes all snapshot definition except host snapshot and its usage.
Bug: 330100430
Bug: 332986564
Test: AOSP CF build succeeded
Change-Id: Ieb6fa43d5e38315c662ce997bc305b744b367c24
As part of the process to remove the compilation action in the top level
java sdk library, this change modifies SdkHeaderJars(...) (i.e. the
"magic") to return the header jar of the implementation library instead
of the header jar of the top level java sdk library when the
implementation jar is returned from the "magic".
This change also removes `SdkImplementationJars()` from the
SdkLibraryDependency interface, as it is not currently used anywhere
else.
Test: m nothing --no-skip-soong-tests
Bug: 332785297
Change-Id: Icc00af4b1485dc2b1b0981a3e56758d0306dea69
droidstubs module require aconfig_declarations modules to be specified
when the module depends on the java_aconfig_library module in order to
generate the "exportable" stubs. This adds burden to the droidstubs or
java_sdk_library module owners, as module should specify both the
java_aconfig_library and aconfig_declarations modules to genreate the
"exportable" stubs, although the necessary information from the
aconfig_declarations module can be provided from the
java_aconfig_library modules.
In order to resolve such burden, this change enables the intermediate
cache files from the associated aconfig_declarations module of a
java_aconfig_library module to be propagated to its reverse dependencies
without having the specify the aconfig_declarations modules in the
droidstubs or java_sdk_library modules definitions.
This does not mean that the intermediate cache files of every transitive
dependencies of the java_sdk_library or the droidstubs will be passed to
aconfig to retrieve the state of the aconfig flags.
Specifically, only the java_aconfig_library modules or the java_library
modules that have static dependency on java_aconfig_library modules that
are passed to droidstubs via `libs` or `srcs` (using
":module_name{.tag}" syntax) will provide the intermediate cache files
to generate the "exportable" stubs. For java_sdk_library, all modules
listed as `libs`, `static_libs`, `stub_only_libs`, and `apiScope.libs`
are passed as `libs` and all modules listed as `api_srcs` and `srcs` are
passed as `srcs` to the droidstubs modules dynamically generated in
java_sdk_library module per api scope, thus these properties will be
affected.
Note that the test is being added in the apex package. This is because
trying to register the codegen package build components in the java
package leads to circular dependency between the codegen and the java
package, as codegen package imports the java package.
Test: m nothing --no-skip-soong-tests
Bug: 329284345
Change-Id: I7953ab64776f6947808321ce8a3598154501bcfe
