Commit eadd1bdb authored Apr 03, 2019 by Jiyong Park

Don't feed framework.jar to proguard for vendor apks

We used to add framework.jar to proguard via -systemjars option even
for the apks building againsd SDK. This was because the app might have
references to hidden APIs via static libraries, etc.

However, for vendor apks, the use of hidden API is strictly prohibited.
So it is fine to not include framework.jar. Furthermore, including
framework.jar even causes problems in some cases; if a java library
(e.g., android.hidl.base-V1.0-java) is statically linked to both the app
and the framework.jar, -systemjars frameworks.jar forcibly removes
classes in the library from the app to have references to the non-public
classes in framework.jar. This could fail some compliance tests.

Fixing the problem by not raising SDK for apks located in vendor or odm
partitions.

Bug: 128574081
Test: m
Change-Id: If2b658fead5b4bb4d8c023a37eb57a37ad9b741d

parent 7369b762

core/java.mk

+7 −0

Original line number	Original line	Diff line number	Diff line
	@@ -395,6 +395,13 @@ else
	# that would break apps that use APIs removed from the current SDK.		# that would break apps that use APIs removed from the current SDK.
	my_proguard_sdk_raise := $(call java-lib-header-files,$(TARGET_DEFAULT_BOOTCLASSPATH_LIBRARIES) $(TARGET_DEFAULT_JAVA_LIBRARIES))		my_proguard_sdk_raise := $(call java-lib-header-files,$(TARGET_DEFAULT_BOOTCLASSPATH_LIBRARIES) $(TARGET_DEFAULT_JAVA_LIBRARIES))
	endif		endif
			ifdef BOARD_SYSTEMSDK_VERSIONS
			ifneq (,$(filter true,$(LOCAL_VENDOR_MODULE) $(LOCAL_ODM_MODULE) $(LOCAL_PROPRIETARY_MODULE)))
			# But for vendor or odm apks, don't raise SDK as the apks are required to
			# use SDK APIs only
			my_proguard_sdk_raise :=
			endif
			endif
	endif		endif

	legacy_proguard_flags := $(addprefix -libraryjars ,$(my_proguard_sdk_raise) \		legacy_proguard_flags := $(addprefix -libraryjars ,$(my_proguard_sdk_raise) \