As auto generated RRO, an arbitrary RRO needs to be exempted as well.
It is okay because RRO packages can access only resource defined in
public.xml, when RRO packages want to refer other package's resource.
Bug: 152926556
Test: build RRO packages
Test: check if product/vendor app still can't use hidden APIs
Change-Id: I8dc2922af5eb5c87ccd97d1b8d080b3ed48cf9a6
Only if PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE is set,
every app and java library in product cannot use hidden APIs anymore.
Bug: 132780927
Test: m
Test: set PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE, and check whether build
error occurs.
Change-Id: Ib6c260a16b9cbb95be70d8db3082a15e151687f1
This change changes auto-generated RROs from DEVICE_PACKAGE_OVERLAYS
to be generated in the vendor partition, as opposed to /product where
they were generated in the past.
Note that PRODUCT_PACKAGE_OVERLAYS continue generating RRO packages
to /product, which means that a single app can be overlayed from
different partitions. These RROs have been given module and package
names based on their location.
Bug: 127758779
Test: verify noop on presubmit targets
Change-Id: I5cee70e28e3969e67b2d83eaf25d9c6e3a11102d
If an RRO is depending on the source module to import its resources,
this trips up the link check because the source module may not be
building against the SDK. Exempt these RROs from the rule.
Bug: 123510624
Test: m
Change-Id: Ie0e05ce6d31dd3a0eafb14ace426da2bc15fb740
For sanity, and to silence the error of not setting
PRIVATE_PLATFORM_APIS or LOCAL_SDK_VERSION.
Exempt framework-res from this, as it can't build against the SDK.
Also tweak the previous whitelisting to be more specifically for
framework-res.
Bug: 118823052
Test: make downstream products
Change-Id: Ia15aaa3b1ea95e02e3483673b668ed2cbca76ba9
When BOARD_SYSTEMSDK_VERSIONS is set, any apk in the vendor partition
is force built against SystemSDK (or Android SDK if LOCAL_SDK_VERSION is
set to current). However, there should be one exception to this: RRO for
framework-res.apk. This is because the RRO is currently overriding
resources that are not part of SystemSDK. Until SystemSDK is expanded to
cover resources that are eligible for overriding, let's allow the direct
dependency from RRO to framework-res.apk.
Bug: 35859726
Bug: 76398918
Test: m -j
Merged-In: Ib9981b107d78691eef21f4525ebdac9866d5c50e
Change-Id: Ib9981b107d78691eef21f4525ebdac9866d5c50e
(cherry picked from commit d8c4c30ba4)
PLATFORM_SYSTEMSDK_VERSIONS is the list of System SDK versions that the
platform is supporting. Contrary to the public SDK where platform
essentially supports all previous SDK versions, platform support only a
few recent System SDK versions, since some of old System APIs are
gradually deprecated, removed from the following SDKs and then finally
deleted from the platform. This will be part of the framework manifest.
The list can be specified by setting PLATFORM_SYSTEMSDK_MIN_VERSION. If
it is set to an old version number, then System SDKs from the version
to the current version (PLATFORM_SDK_VERSION) are considered to be
supported by the platform. If PLATFORM_SYSTEMSDK_MIN_VERSION is not set,
only the latest System SDK version is supported.
Next, BOARD_SYSTEMSDK_VERSIONS is the list of System SDK versions that
the device is using. This is put to the device compatibility matrix
device is using. The device and the platform is considered as compatible
only BOARD_SYSTEMSDK_VERSIONS in the device compatibility matrix are
in the PLATFORM_SYSTEMSDK_VERSIONS in the framework manifest.
When BOARD_SYSTEMSDK_VERSIONS is set, a Java app or library in vendor or
odm partitions which didn't specify LOCAL_SDK_VERSION is forced to use
System SDK. Also, the build system does the additional integrity check
to ensure that LOCAL_SDK_VERSION is within BOARD_SYSTEMSDK_VERSIONS or
PLATFORM_SYSTEMSDK_VERSIONS (if BOARD_SYSTEMSDK_VERSIONS isn't set).
Bug: 69088799
Test: m -j
Test: BOARD_SYSTEMSDK_VERSIONS=P m -j
Change-Id: If4d59f6030e4cc402e015701d0caf94aeec37263
Jeongik Cha