| commit | e3c278844d18c18fb0ad9150414dcc45822b89a1 | [log] [tgz] |
|---|---|---|
| author | Jiyong Park <jiyong@google.com> | Tue Jan 02 18:40:42 2024 +0900 |
| committer | Jiyong Park <jiyong@google.com> | Wed Jan 03 16:35:08 2024 +0900 |
| tree | c1c163bfb1297238284e19d9380099937ff60fb6 | |
| parent | 2e137a99636b16f8295312ec074f14fc26a716d0 [diff] |
Limit System SDK to 34 for Java modules in the vendor partition This change disallows Java modules in the vendor partition to use System SDK that is newer than API level 34; 34 is the latest allowed. Background 1: with Trunk Stable, the system/vendor interface is released at Q2 whereas the system/app interface is released at Q3. In other words, at Q2, the APIs which will be added to the system SDK at Q3 are not available. Since the system/vendor interface (which is fronzen at Q2) is what the modules in the vendor partition will be building against, they can't and shouldn't use those new APIs that will be added in the future (Q3). Using those APIs is risky because there's a chance that those APIs get removed or changed between Q2 and Q3. For example, 2024 Q2 is technically still Android U, not Android V. Background 2: The use of Java APIs in the vendor partition had many issues. Most significantly, those "vendor" Java apps are categorized as part of the system partition because all Java app processes require access to platform internal libraries that are prohibited to vendor processes. Furthermore, since the Project Treble, the vendor partition was re-purposed to a partition to host SoC-dependent bits - usually HALs. Implementing HALs in Java has never been officially supported and has had many loop holes. We'd like to use both background 1 and 2 as a chance to disallow any Java code in the vendor partition. However, since there are already some Java modules in the partition, we can't suddenly ban it. The deprecation will be made gradually, and this CL is the start. This CL implements the "Make" part of the restriction. The "Soong" part will follow. Note that LOCAL_SDK_VERSION := current or LOCAL_SDK_VERSION := system_current is automatically overridden into 34 or system_34. This is to prevent sudden breakage of vendor modules that have been targetting the latest (i.e. current) API level. They will however fail if they use APIs newer than API level 34. Bug: 314011075 Test: The following Android.mk module fails as expected. some/Android.mk: include $(CLEAR_VARS) LOCAL_MODULE := example_module LOCAL_VENDOR_MODULE := true LOCAL_SDK_VERSION := system_35 LOCAL_SRC_FILES := Foo.java include $(BUILD_JAVA_LIBRARY) FAILED: some/Android.mk: error: example_module: Incompatible LOCAL_SDK_VERSION 'system_35'. System SDK version '35' is not supported. Supported versions are: 28 29 30 31 32 33 34 Change-Id: I44c29c6dc45b91a9a30b8a21cd2baae685fa27fb
This is the Makefile-based portion of the Android Build System.
For documentation on how to run a build, see Usage.txt
For a list of behavioral changes useful for Android.mk writers see Changes.md
For an outdated reference on Android.mk files, see build-system.html. Our Android.mk files look similar, but are entirely different from the Android.mk files used by the NDK build system. When searching for documentation elsewhere, ensure that it is for the platform build system -- most are not.
This Makefile-based system is in the process of being replaced with Soong, a new build system written in Go. During the transition, all of these makefiles are read by Kati, and generate a ninja file instead of being executed directly. That's combined with a ninja file read by Soong so that the build graph of the two systems can be combined and run as one.