Original Commit Message:
"""
Rename modules that are APEX-only
The renamed modules are only available for APEXes, but not for the
platform. Use the <module_name>.<apex_name> syntax to correctly install
the APEX variant of the modules.
"""
Reason for revert: Build Cop - Breaks about 15 AOSP targets, with high confidence due to these changes being the only non-robot changes in those builds.
Reverted Changes:
I190ce2d10:Use apex_available property
I990e0a67e:Use apex_available property
I0d1295683:Revert "Avoid duplicated classes for boot dex jars...
I5fb725403:Find the jar libraries in APEX from the correct pa...
I322b1efcc:Rename modules that are APEX-only
Ifa2bd0f8f:Use apex_available property
Iac6533177:Use apex_available property
Ie999602c6:Use apex_available property
I2a3d73397:Use apex_available property
Ic91bcbb9a:Use apex_available property
Ia6c324eed:Use apex_available property
I964d0125c:Use apex_available property
Change-Id: I48b998629b0676cd7353e6844fd87585e0e42989
Java modules using SystemAPI can now link against platform owned
sysprop_library with public stub. This allows modules to use platform's
public sysprops (which should be regarded as an API) without any hidden
API usages, if using dynamic linking and boot class path.
This doesn't affect any vendor or odm owned sysprop_library.
Bug: 141246285
Bug: 145167888
Test: m
Change-Id: I99824fb24a75cc8282211c2ad6c6296ae9fca393
Previously, the compat configs from static dependencies were all written
to compat/compat_config.xml, putting at the mercy of jar file merging and
so potentially losing some config.
Now the annotation processor writes a compat_config.xml for each Java
class that exports config, we we merge them together here with a new
tool.
Test: m
Change-Id: I28c12ff648a01aaad214701fca4f09743638b11b
The filesystem object was available through ModuleContext.Fs(), but
gives too much access to the filesystem without enforicing correct
dependencies. In order to support sandboxing the soong_build
process move the filesystem into the Config. The next change will
make it private.
Bug: 146437378
Test: all Soong tests
Change-Id: I5d3ae9108f120fd335b21efd612aefa078378813
Previous CL Ia9b34aa92ebb1b4de96ea0f8f290d798be19b2cf introduced
asymmetry in handling "boot" and "apex" boot images: in JIT-zygote
experiment, though the "apex" boot image was installed, the "boot"
boot image was still used for generating dexpreopt configs.
It is unclear why this asymmetry was needed at that point; it seems
incorrect to use different boot images for dexpreopting and for
installing on device. After recent changes the asymmetry started
breaking walleye_jitzygote-userdebug on git_rvc-release, because APK
dexpreopt commands refer to inexistent boot image files.
Test: lunch aosp_walleye-userdebug && m
Test: cherry-pick CL in internal, walleye_jitzygote-userdebug boots
Change-Id: Id877c10269cf79caf6ae74b1dc169a31e6a2211b
The module framework is now a build-only library whose purpose is to
provide hidden APIs from the non-updatable part of the platform and APIs
from the modules. Merging updatable_media_stub to framework, like the
stub libraries from other modules.
As a result, updatable_media_stub can be removed from DefaultLibraries.
Bug: N/A
Test: m
Change-Id: I7f80716119ad6ac627e5666def9fe17112dcde3b
This time, exclude NDK libraries instead of LLNDK libraries from the
package. This is necessary because there are libraries such as libvndksupport
which are LLNDK but are not accessible to apps.
Original commit message:
> Previously, android_app targets for which a.shouldEmbedJnis(ctx) = true
> (e.g. CtsSelinuxTargetSdk25TestCases) would need to specify all of their
> recursive library dependencies, including for example libc++ when depending
> on the platform libc++. This means unnecessary churn when we add a new
> dependency to libc++ (e.g. libunwind [1]). To avoid the churn and allow
> jni_libs clauses to be simplified, make the build system search for the
> recursive dependencies and automatically include them.
>
> This change allows us to remove code that was previously adding NDK libc++
> as a special case, as it is now covered by the generic code.
>
> Also fix some improper quoting that was exposed as a result of this change
> causing more files to be packaged than before.
>
> [1] https://android-review.googlesource.com/q/topic:%22libunwind-so%22
Bug: 144430859
Test: atest CtsAppOpsTestCases
Test: atest FrameworksNetSmokeTests
Change-Id: I8311ede0b44d7e50b9f272912ead8ef07e82b074
Enable jacoco for ike.jar to set up code coverage. ike will be
shipped in mainline module com.android.ipsec
Bug: 146012420
Test: m EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true SKIP_BOOT_JARS_CHECK=true WITH_DEXPREOPT=false
Change-Id: I886551d980c0d9651b11c80051f17609bb3531d8
It needs to be an implicit input for it to work consistently.
Test: m GooglePermissionControllerUnitTests
Bug: 145011263
Change-Id: Ib71d768e750faa5b577652e79a18d05929bde52f
This reverts commit 2812df4edb.
This is no longer required as we have
I6463ebc59cf7fd861b812999d7a79c387bbb3335.
hostdex files are available even when the module doesn't have
"//apex_available:platform"
Bug: 128708192
Test: m
Change-Id: I0d1295683222bc9cdbb82630e61ab3421c717daf
Previously, android_app targets for which a.shouldEmbedJnis(ctx) = true
(e.g. CtsSelinuxTargetSdk25TestCases) would need to specify all of their
recursive library dependencies, including for example libc++ when depending
on the platform libc++. This means unnecessary churn when we add a new
dependency to libc++ (e.g. libunwind [1]). To avoid the churn and allow
jni_libs clauses to be simplified, make the build system search for the
recursive dependencies and automatically include them.
This change allows us to remove code that was previously adding NDK libc++
as a special case, as it is now covered by the generic code.
Also fix some improper quoting that was exposed as a result of this change
causing more files to be packaged than before.
[1] https://android-review.googlesource.com/q/topic:%22libunwind-so%22
Bug: 144430859
Change-Id: I3d6fbcce75bc108a982eb7483992a4b202056339
Java libraries with hostdex: true are available for the platform even if
it doesn't have "//apex_available:platform" in the apex_available
property. Note that the java libraries are still prevented from being
installed to the device.
Bug: 128708192
Test: m
Change-Id: I6463ebc59cf7fd861b812999d7a79c387bbb3335
When a boot classpath java library is directly or indirectly included in
APEXes, multiple variant of the library exist. When running the
hiddenapi tool, we need to eliminate the duplication, otherwise the tool
will complain.
Previously, we simply choose the platform variant of the java library
among the multiple variants. However, if the java library is marked not
available for the platform (i.e. "//apex_available:platform" is not in
the apex_available property), the platform variant does not exist and
thus it is not fed into the hiddenapi tool, which causes missing
references in the tool.
To solve the problem, the platform variant is selected only for the java
libs that are available for the platform. For those libs that are not
available for the platform, we choose one variant of it using a
heuristic; skip testing APEXes and choose com.android.art.release among
the com.android.art.* variants.
Bug: 128708192
Test: m
Change-Id: I33bf297eb3029696ae3504a011486210708fb2c2
Use the empty string for the core image variant so that modules
added to imageMutator do not change their build directory.
Bug: 142286466
Test: m checkbuild
Change-Id: Ida4534d9a4d6176236aaa480fed359ce27acfaa1
Merged-In: Ida4534d9a4d6176236aaa480fed359ce27acfaa1
(cherry picked from commit 72d685ee7f45e5393be44ae4159edf083ac918de)
Use the empty string for the core image variant so that modules
added to imageMutator do not change their build directory.
Bug: 142286466
Test: m checkbuild
Change-Id: Ida4534d9a4d6176236aaa480fed359ce27acfaa1
Previously, adding a new SdkMemberType would require adding a new
sdkMemberListProperty instance to the sdkMemberListProperties as well
as adding a new property into the sdkProperties struct. They are
potential sources of conflict and couple the sdk code with all the
packages that add members to it. This change switched to a
registration model that allows each package to register its sdk
member types decoupling them from the sdk code.
Adds an SdkPropertyName() method to SdkMemberType that specifies the
name of the property to use in the sdk/sdk_snapshot. Also provides
an SdkMemberTypeBase struct to be used by providers of SdkMemberType
implementations.
SdkMemberType instances are registered using the
RegisterSdkMemberType() func which sorts the registered instances
by their SdkPropertyName() to ensure the behavior is consistent and
not affected by order of registration.
When creating a new sdk module a dynamicSdkMemberTypes instance is
created that contains the following:
* A properties struct is created dynamically that contains a field for
each registered SdkMemberType, corresponding to that type's
SdkPropertyName().
* A list of sdkMemberListProperty instances is also created, one for
each registered SdkMemberType.
The dynamicSdkMemberTypes instance is cached using a key that uniquely
identifies the set of registered types just in case new types are
registered after one has been created, e.g. by tests.
Bug: 142918168
Test: m checkbuild
Change-Id: I4bf2bf56a2a49025aa41454048bc1e8ccc6baca2
