This reverts commit 17d69e3484.
Reason for revert: This new field is not useful without dependencies in aosp
Test: builds
Change-Id: I87bd820cd6dbc5274ce3d28c4578381718aa805d
Merged-In: I70d6f7dc751510311b03e245b2189a76b395a49c
kapt claims to support a comma separated list of annotation
processors, but it errors if multiple annotation processors
are given. Surrounding the the list with {} does not error,
but it also doesn't even warn if the second element in the
list is garbage, so it may not be running the second
processor. Repeat the processor argument for each
annotation processor class instead.
Bug: 154736649
Test: TestKapt
Test: m checkbuild
Change-Id: I4c7c161dbf867d7fba1aaf16fd5e502647e3f682
Merged-In: I4c7c161dbf867d7fba1aaf16fd5e502647e3f682
(cherry picked from commit 5a11686e64)
kapt claims to support a comma separated list of annotation
processors, but it errors if multiple annotation processors
are given. Surrounding the the list with {} does not error,
but it also doesn't even warn if the second element in the
list is garbage, so it may not be running the second
processor. Repeat the processor argument for each
annotation processor class instead.
Bug: 154736649
Test: TestKapt
Test: m checkbuild
Change-Id: I4c7c161dbf867d7fba1aaf16fd5e502647e3f682
Previously, adding java_library to an sdk required that the names of
any APEXes that transitively compiled against it were added to its
apex_available property. This change removes that requirement.
Also corrects the dependency path in the TestApexAvailable_IndirectDep
error which previously passed through "shared from static" static
dependency tags even though those are explicitly NOT followed when
checking apex_available settings.
Bug: 152878661
Bug: 153306490
Test: m droid
Merged-In: I995ed38956c1bc210b09494812de012fed9f9232
Change-Id: I995ed38956c1bc210b09494812de012fed9f9232
Previously, java snapshot properties (java_library and java_test)
relied on the properties not being optimized when there was a single os
type and instead being added directly to the common os type properties.
However, that means that the behavior is inconsistent for other member
types depending on whether there was one os type or not.
This change updates the java sdk member handling to support
optimization. This involved:
1) Adding AidlIncludeDirs field to librarySdkMemberProperties to
specify the aidl include dirs instead of extracting that from the
library field.
2) Renaming jarToExport to JarToExport (in both
library/testSdkMemberProperties)to allow it to be optimized.
3) Adding MemberType() and Name() methods to SdkMemberPropertiesContext
to avoid having to store the former in the properties struct and
retrieve the latter from the library/test fields.
4) Removing the now unused library/test fields from the properties
structures.
5) Separating the processing of the jar/test config in
AddToPropertySet(...) as they may be optimized separately.
6) Ditto for the jar/aidl include dirs.
7) While doing this work I noticed that although the contents of the
aidl include dirs are copied into the snapshot the java_import does
not make use of them. Raised bug 151933053 and added TODO to track
that work.
Bug: 142935992
Bug: 153306490
Test: m nothing
Merged-In: Iba9799e111ca5672b2133568163d8c49837ba9cd
Change-Id: Iba9799e111ca5672b2133568163d8c49837ba9cd
Previously passing additional information to the implementations of
AddPrebuiltModule() or the SdkMemberProperties interface would have
required making changes to the API. This change added an
SdkMemberContext object into which additional information can easily
be added without requiring changes to existing implementations.
The BuildSnapshot() method was not modified because it is deprecated
and will be removed in a follow up change.
It also switches the API from passing variants as android.SdkAware to
android.Module. That is for a couple of reasons:
1) SdkAware is designed for managing the relationship between the
module and the SDK, not for generating the output snapshot. As such
there is nothing in SdkAware that is needed for generating the
output snapshot.
2) Accepting android.Module instead makes it easier to use the
underlying code for generating the snapshot module as well as the
individual member modules.
This is in preparation for a number of improvements and bug fixes in
both the snapshot creation code and implementations to address found
while trying to built the platform against ART prebuilts.
Bug: 151937654
Bug: 153306490
Test: m nothing
Merged-In: Iac10f1200c0f283aa35402167eec8f9aeb65a38e
Change-Id: Iac10f1200c0f283aa35402167eec8f9aeb65a38e
Updates the member snapshot creation code to support multiple os types.
It basically sorts the variants by os type, then applies the code to
optimize the arch properties and then it optimizes the properties that
are common across architectures and extracts any properties that are
common across os types.
The java and cc member types needed to be modified to make the location
of the generated files within the snapshot os type dependent when there
is more than one os type. That was done by adding an OsPrefix() method
to the SdkMemberPropertiesBase which returns the os prefix to use when
there is > 1 os type and otherwise returns an empty string.
Added three tests, one for cc shared libraries, one for cc binary and
one for java header libraries.
Bug: 150451422
Bug: 153306490
Test: m nothing
Merged-In: I08f5fbdd7852b06c9a9a2f1cfdc364338a3d5bac
Change-Id: I08f5fbdd7852b06c9a9a2f1cfdc364338a3d5bac
Adds support for handling the common arch to the sdk module type
snapshot generation code and then refactors the java_library
and java_test snapshot processing to take advantage of that.
Bug: 150451422
Bug: 153306490
Test: m nothing
Merged-In: If746f375f1c4288ab6b67c7d216593b70258b043
Change-Id: If746f375f1c4288ab6b67c7d216593b70258b043
Adds the accessor function for retrieving the impl/header jars to the
librarySdkMemberType structure instead of passing it into its
buildSnapshot() method.
That enabled:
* The removal of the [header/impl]LibrarySdkMemberType structs.
* The removal of their implementations of BuildSnapshot.
* Replacing buildSnapshot() with BuildSnapshot()
This will make subsequent refactoring of the SdkMemberType interface
a little simpler.
Bug: 153306490
Test: m nothing
Bug: 150451422
Merged-In: I1f96986bb497cf9d9df9916e40065f66b35a4704
Change-Id: I1f96986bb497cf9d9df9916e40065f66b35a4704
As a follow up, this property will be set to APKs participating in mainline program.
Bug: 153333044
Test: m
Change-Id: I6ea2f3c1d26992259e4e9e6a6d8cecf091d39c43
Merged-In: I6ea2f3c1d26992259e4e9e6a6d8cecf091d39c43
(cherry picked from commit 2db1c3f1c4)
Exempt-From-Owner-Approval: clean cherry-pick
As a follow up, this property will be set to APKs participating in mainline program.
Bug: 153333044
Test: m
Change-Id: I6ea2f3c1d26992259e4e9e6a6d8cecf091d39c43
Previously, adding java_library to an sdk required that the names of
any APEXes that transitively compiled against it were added to its
apex_available property. This change removes that requirement.
Also corrects the dependency path in the TestApexAvailable_IndirectDep
error which previously passed through "shared from static" static
dependency tags even though those are explicitly NOT followed when
checking apex_available settings.
Bug: 152878661
Test: m droid
Change-Id: I995ed38956c1bc210b09494812de012fed9f9232
If "v4_signature: true" is set, the v4 signature file,
named [outputApkFile].idsig
will be generated along side the outputApkFile.
Test: m nothing
Test: atest PackageManagerShellCommandIncrementalTest
BUG: 149354175
Change-Id: Ie84725a15406f96f65042ea9909460e4eb34d57f
Merged-In: Ie84725a15406f96f65042ea9909460e4eb34d57f
Make java_library support this mode of output, to allow
callers to dist the classes.jar file rather than the dexed
jar file.
Bug: 152618077
Test: followup CL
Change-Id: I5ba6949833a0fbb95376142aec5096ff5f084c00
Merged-In: I5ba6949833a0fbb95376142aec5096ff5f084c00
(cherry picked from commit 1e65f94a4b)
Make java_library support this mode of output, to allow
callers to dist the classes.jar file rather than the dexed
jar file.
Bug: 152618077
Test: followup CL
Change-Id: I5ba6949833a0fbb95376142aec5096ff5f084c00
This is a cherry-pick change.
Test: Built mainline module coverage data
Bug: 152117890
Change-Id: I47bf3e5d6e78c4518729bdb52616e248156d3cec
Merged-In: I47bf3e5d6e78c4518729bdb52616e248156d3cec
If "v4_signature: true" is set, the v4 signature file,
named [outputApkFile].idsig
will be generated along side the outputApkFile.
Test: m nothing
Test: atest PackageManagerShellCommandIncrementalTest
BUG: 149354175
Change-Id: Ie84725a15406f96f65042ea9909460e4eb34d57f
Include the module_api stubs in system_server one instead of
putting both of these jars on the classpath. Also rename it
to be in line with the other stubs.
Bug: 149293194
Test: m
Exempt-From-Owner-Approval: approved internally
Change-Id: Iead5af4152a49cd59a4fd7afc0312c2f0c872c1e
Merged-In: Iead5af4152a49cd59a4fd7afc0312c2f0c872c1e
(cherry picked from commit bbd78556da)
This reworks CL https://r.android.com/1180134 as follows:
1) Do not reorder the list of system server jars passed from Make to
Soong via the product variable PRODUCT_SYSTEM_SERVER_JARS. This means
that for some products the order of jars on the system server
classpath may be non-optimal: a jar X that depends on Y may be
dexpreopted before Y, so that all references to the classes and
methods from Y wil be unresolved.
Unfortunately for such products, fixing the order is not a simple
matter of rearranging their PRODUCT_SYSTEM_SERVER_JARS, because the
conflicts may arise when the product-specific variable gets merged
with the common variable.
2) As a consequence of 1), do not add artificial dependencies between
system server jars: this is now impossible, as it would create
circular dependencies for those products that have non-optimal order
of jars.
3) Copy dex files for system server jars to a predefined build location.
This is necessary because at the time when Soong generates class
loader context for k-th jar, it needs to know the paths to jars 1 ..
(k-1), and it might have not processed those jars yet (so Soong can't
query the paths from the modules).
This approach is similar to the way Soong handles bootclasspath jars.
4) Do not exclude from dexpreopting system server jars that are not
Soong modules (those that are Make modules). The previous CL excluded
them because Make modules do not have ModuleContext. But it turns out
that ModuleContext is not necessary, as all the information is passed
via the dexpreopt config.
Test: aosp_walleye-userdebug boots and there are no messages in the
logcat regarding class loader context mismatch:
$ adb logcat | grep 'mismatch'
# empty
Test: Class loader contexts in the oat files for system server jars
match expectations:
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/com.android.location.provider.odex 2>/dev/null | grep '^classpath'
classpath = PCL[]
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/services.odex 2>/dev/null | grep '^classpath'
classpath = PCL[/system/framework/com.android.location.provider.jar*1989208671]
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/ethernet-service.odex 2>/dev/null | grep '^classpath'
classpath = PCL[/system/framework/com.android.location.provider.jar*1989208671:/system/framework/services.jar*4040443083:/system/framework/services.jar!classes2.dex*2210087472]
Test: The phone boots and logcat has no scary messages related to
class loader contexts:
$ lunch aosp_walleye-userdebug && m
$ adb reboot bootloader && fastboot flashall -w && adb wait-for-device
$ adb root
$ adb shell stop
$ adb logcat -c
$ adb shell setprop dalvik.vm.extra-opts -verbose:oat
$ adb shell start
$ adb logcat | egrep -io 'system_server: .*load.*/system/framework.*'
system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/services.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/services.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/ethernet-service.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/ethernet-service.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/wifi-service.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/wifi-service.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/services.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/services.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/ethernet-service.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/ethernet-service.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/wifi-service.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/wifi-service.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
Bug: 141785760
Bug: 140451054
Bug: 148944771
Bug: 147017252
Change-Id: I33c4087f8bfacd0ecb89877aa150b75360d06710
Merged-In: I33c4087f8bfacd0ecb89877aa150b75360d06710
(cherry picked from commit a4a83b0ef9)
Exempt-From-Owner-Approval: cherry-pick.
Previously, java snapshot properties (java_library and java_test)
relied on the properties not being optimized when there was a single os
type and instead being added directly to the common os type properties.
However, that means that the behavior is inconsistent for other member
types depending on whether there was one os type or not.
This change updates the java sdk member handling to support
optimization. This involved:
1) Adding AidlIncludeDirs field to librarySdkMemberProperties to
specify the aidl include dirs instead of extracting that from the
library field.
2) Renaming jarToExport to JarToExport (in both
library/testSdkMemberProperties)to allow it to be optimized.
3) Adding MemberType() and Name() methods to SdkMemberPropertiesContext
to avoid having to store the former in the properties struct and
retrieve the latter from the library/test fields.
4) Removing the now unused library/test fields from the properties
structures.
5) Separating the processing of the jar/test config in
AddToPropertySet(...) as they may be optimized separately.
6) Ditto for the jar/aidl include dirs.
7) While doing this work I noticed that although the contents of the
aidl include dirs are copied into the snapshot the java_import does
not make use of them. Raised bug 151933053 and added TODO to track
that work.
Bug: 142935992
Test: m nothing
Change-Id: Iba9799e111ca5672b2133568163d8c49837ba9cd
Previously passing additional information to the implementations of
AddPrebuiltModule() or the SdkMemberProperties interface would have
required making changes to the API. This change added an
SdkMemberContext object into which additional information can easily
be added without requiring changes to existing implementations.
The BuildSnapshot() method was not modified because it is deprecated
and will be removed in a follow up change.
It also switches the API from passing variants as android.SdkAware to
android.Module. That is for a couple of reasons:
1) SdkAware is designed for managing the relationship between the
module and the SDK, not for generating the output snapshot. As such
there is nothing in SdkAware that is needed for generating the
output snapshot.
2) Accepting android.Module instead makes it easier to use the
underlying code for generating the snapshot module as well as the
individual member modules.
This is in preparation for a number of improvements and bug fixes in
both the snapshot creation code and implementations to address found
while trying to built the platform against ART prebuilts.
Bug: 151937654
Test: m nothing
Change-Id: Iac10f1200c0f283aa35402167eec8f9aeb65a38e
This reworks CL https://r.android.com/1180134 as follows:
1) Do not reorder the list of system server jars passed from Make to
Soong via the product variable PRODUCT_SYSTEM_SERVER_JARS. This means
that for some products the order of jars on the system server
classpath may be non-optimal: a jar X that depends on Y may be
dexpreopted before Y, so that all references to the classes and
methods from Y wil be unresolved.
Unfortunately for such products, fixing the order is not a simple
matter of rearranging their PRODUCT_SYSTEM_SERVER_JARS, because the
conflicts may arise when the product-specific variable gets merged
with the common variable.
2) As a consequence of 1), do not add artificial dependencies between
system server jars: this is now impossible, as it would create
circular dependencies for those products that have non-optimal order
of jars.
3) Copy dex files for system server jars to a predefined build location.
This is necessary because at the time when Soong generates class
loader context for k-th jar, it needs to know the paths to jars 1 ..
(k-1), and it might have not processed those jars yet (so Soong can't
query the paths from the modules).
This approach is similar to the way Soong handles bootclasspath jars.
4) Do not exclude from dexpreopting system server jars that are not
Soong modules (those that are Make modules). The previous CL excluded
them because Make modules do not have ModuleContext. But it turns out
that ModuleContext is not necessary, as all the information is passed
via the dexpreopt config.
Test: aosp_walleye-userdebug boots and there are no messages in the
logcat regarding class loader context mismatch:
$ adb logcat | grep 'mismatch'
# empty
Test: Class loader contexts in the oat files for system server jars
match expectations:
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/com.android.location.provider.odex 2>/dev/null | grep '^classpath'
classpath = PCL[]
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/services.odex 2>/dev/null | grep '^classpath'
classpath = PCL[/system/framework/com.android.location.provider.jar*1989208671]
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/ethernet-service.odex 2>/dev/null | grep '^classpath'
classpath = PCL[/system/framework/com.android.location.provider.jar*1989208671:/system/framework/services.jar*4040443083:/system/framework/services.jar!classes2.dex*2210087472]
Test: The phone boots and logcat has no scary messages related to
class loader contexts:
$ lunch aosp_walleye-userdebug && m
$ adb reboot bootloader && fastboot flashall -w && adb wait-for-device
$ adb root
$ adb shell stop
$ adb logcat -c
$ adb shell setprop dalvik.vm.extra-opts -verbose:oat
$ adb shell start
$ adb logcat | egrep -io 'system_server: .*load.*/system/framework.*'
system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/services.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/services.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/ethernet-service.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/ethernet-service.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/wifi-service.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/wifi-service.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/services.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/services.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/ethernet-service.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/ethernet-service.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/wifi-service.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/wifi-service.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
Bug: 141785760
Bug: 140451054
Bug: 148944771
Bug: 147017252
Change-Id: I33c4087f8bfacd0ecb89877aa150b75360d06710
Include the module_api stubs in system_server one instead of
putting both of these jars on the classpath. Also rename it
to be in line with the other stubs.
Bug: 149293194
Test: m
Change-Id: Iead5af4152a49cd59a4fd7afc0312c2f0c872c1e
Checking apex_available was missing some corner cases.
For example, the deps of share deps of cc_library modules are missed
while those from cc_library_shared are correctly tracked.
This was due to..
* calling DepIsInSameApex in WalkDeps: both work fine separately, but
when they are used together, it fails to work. It's due to how WalkDeps
works. (We might fix this bug too risky since it is used very widely)
* incorrect receiver for DepIsInSameApex in apex_deps mutator: receiver
is supposed to be parent, but child was used before. Interestingly lots
of deps are within the same group of module types(cc to cc, java to
java), it has worked. (note that receiver's DepIsInSameApex
implementation can be different).
This change fixes them by..
* walkPayloadDeps is now relying on ApexVariation, which is calculated
correctly by TopDown apex_deps mutator.
* use correct receiver for DepIsInSameApex in apex_deps mutator, which
requires for java.SdkLibrary to override the method and for
java.Library/Import to use passed dep instead of receiver to check its
membership of sdk.
Exempt-From-Owner-Approval: cherry-pick from aosp/master
Bug: 151071238
Test: build/boot
Merged-In: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
(cherry picked from commit 5e9013be22)
Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
Checking apex_available was missing some corner cases.
For example, the deps of share deps of cc_library modules are missed
while those from cc_library_shared are correctly tracked.
This was due to..
* calling DepIsInSameApex in WalkDeps: both work fine separately, but
when they are used together, it fails to work. It's due to how WalkDeps
works. (We might fix this bug too risky since it is used very widely)
* incorrect receiver for DepIsInSameApex in apex_deps mutator: receiver
is supposed to be parent, but child was used before. Interestingly lots
of deps are within the same group of module types(cc to cc, java to
java), it has worked. (note that receiver's DepIsInSameApex
implementation can be different).
This change fixes them by..
* walkPayloadDeps is now relying on ApexVariation, which is calculated
correctly by TopDown apex_deps mutator.
* use correct receiver for DepIsInSameApex in apex_deps mutator, which
requires for java.SdkLibrary to override the method and for
java.Library/Import to use passed dep instead of receiver to check its
membership of sdk.
Bug: 151071238
Test: build/boot
Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
Updates the member snapshot creation code to support multiple os types.
It basically sorts the variants by os type, then applies the code to
optimize the arch properties and then it optimizes the properties that
are common across architectures and extracts any properties that are
common across os types.
The java and cc member types needed to be modified to make the location
of the generated files within the snapshot os type dependent when there
is more than one os type. That was done by adding an OsPrefix() method
to the SdkMemberPropertiesBase which returns the os prefix to use when
there is > 1 os type and otherwise returns an empty string.
Added three tests, one for cc shared libraries, one for cc binary and
one for java header libraries.
Bug: 150451422
Test: m nothing
Change-Id: I08f5fbdd7852b06c9a9a2f1cfdc364338a3d5bac
Adds support for handling the common arch to the sdk module type
snapshot generation code and then refactors the java_library
and java_test snapshot processing to take advantage of that.
Bug: 150451422
Test: m nothing
Change-Id: If746f375f1c4288ab6b67c7d216593b70258b043
Adds the accessor function for retrieving the impl/header jars to the
librarySdkMemberType structure instead of passing it into its
buildSnapshot() method.
That enabled:
* The removal of the [header/impl]LibrarySdkMemberType structs.
* The removal of their implementations of BuildSnapshot.
* Replacing buildSnapshot() with BuildSnapshot()
This will make subsequent refactoring of the SdkMemberType interface
a little simpler.
Test: m nothing
Bug: 150451422
Change-Id: I1f96986bb497cf9d9df9916e40065f66b35a4704
hiddenapi expects that all members in a class to have corresponding hidden
API flags. However, this can't be satisfied when the java module having
the class is instrumented; JaCoCo added a few number of synthetic
members. In this case, give 'no-force-assign-all' option to the hidden
api tool so that it doesn't complain about the synthetic methods.
Also, disabling instrumenting jacocoagent itself, because it doesn't
make sense.
Exempt-From-Owner-Approval: PS3 fixes a typo in a comment. PS2 got ORV.
Bug: 149353192
Test: SKIP_ABI_CHECKS=true EMMA_INSTRUMENT=true
EMMA_INSTRUMENT_FRAMEWORK=true SKIP_BOOT_JARS_CHECK=true m
out/soong/.intermediates/external/apache-xml/apache-xml/android_common_com.android.art.debug/hiddenapi/unaligned/unaligned.jar
Merged-In: Ibaf383c439945ab664e885af319548b56e2c8cb6
(cherry picked from commit 93e57a0b86)
Change-Id: Ibaf383c439945ab664e885af319548b56e2c8cb6
This reverts commit c021ea0b35.
Exempt-From-Owner-Approval: cherry-pick from aosp
Bug: 149353192
Merged-In: I2b1c0736202de26c5ea88c0ab14574bd7207a5fb
Test: N/A (this is a clean revert) forward fix will be followed
(cherry picked from commit 00cae1cc88)
Change-Id: I2b1c0736202de26c5ea88c0ab14574bd7207a5fb
hiddenapi expects that all members in a class to have corresponding hidden
API flags. However, this can't be satisfied when the java module having
the class is instrumented; JaCoCo added a few number of synthetic
members. In this case, give 'no-force-assign-all' option to the hidden
api tool so that it doesn't complain about the synthetic methods.
Also, disabling instrumenting jacocoagent itself, because it doesn't
make sense.
Exempt-From-Owner-Approval: PS3 fixes a typo in a comment. PS2 got ORV.
Bug: 149353192
Test: SKIP_ABI_CHECKS=true EMMA_INSTRUMENT=true
EMMA_INSTRUMENT_FRAMEWORK=true SKIP_BOOT_JARS_CHECK=true m
out/soong/.intermediates/external/apache-xml/apache-xml/android_common_com.android.art.debug/hiddenapi/unaligned/unaligned.jar
Change-Id: Ibaf383c439945ab664e885af319548b56e2c8cb6
This reverts commit c021ea0b35.
Bug: 149353192
Change-Id: I2b1c0736202de26c5ea88c0ab14574bd7207a5fb
Test: N/A (this is a clean revert) forward fix will be followed
Sharding uses the header jar of all of the classes of the module
with the sources of a subset, but was incorrectly used the jarjar
version of the header jar, which may have renamed some of the
classes.
Fixes: 149969343
Test: m framework-minus-apex
Change-Id: I568c939f8030d3ddc1e7fa8796cffcac4d6172e8
Merged-In: I568c939f8030d3ddc1e7fa8796cffcac4d6172e8
(cherry picked from commit f5a6628b27)
Sharding uses the header jar of all of the classes of the module
with the sources of a subset, but was incorrectly used the jarjar
version of the header jar, which may have renamed some of the
classes.
Fixes: 149969343
Test: m framework-minus-apex
Change-Id: I568c939f8030d3ddc1e7fa8796cffcac4d6172e8
