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.
Note that sdk_version: "current" or "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: m blueprint_tests
Change-Id: I59f5ac15ce9ac2ff7cc89e9c110169359077c37c
This allows us to set product variables as build settings instead
of loading them from a target's provider, which further allows us
to read product config variables in transitions.
Bug: 287539062
Bug: 269577299
Test: Presubmits
Change-Id: I8497703f706162572ceb3486240e1eb02a37f5f6
This product is experimental and unsupported for Bazel at this time
Test: lunch aosp_riscv64-userdebug && m nothing
Test: lunch aosp_arm64-userdebug && m nothing
Change-Id: I761afb9524f1008f9d5472d2de19bb84342e9e29
Previously, CommonOs was not added to Config.Targets for the test which
caused AndroidMk to crash when trying to determine if a target needed
the 2ND_ prefix added to some make variables.
Bug: 245956352
Test: m nothing
Change-Id: Ia815537ee5ce8e83df9a01c57250aa888453d138
Use Target.Os and Target.HostCross as the key in FirstTarget so that
it returns a separate target for host and host cross architectures.
This is useful when host and host cross are both linux_musl, but
host cross is an independenct architecture like arm64.
Also filter the targets returned by ctx.MultiTargets() to match
the HostCross value of ctx.Target() to prevent the newly created
HostCross variants from colliding with Host variants in JNI or
test data attached to Java targets using a common arch.
This relands If75790001afe9d0f9d4d8166f207847851812297 with the
addition of the ctx.MultiTargets() filtering.
Bug: 236052820
Test: TestArchMutator
Change-Id: Ia6fe1185915d174d0ad6b401c227e0e57bee5c24
