Disable VNDK apexes when their version is below the minimum
supported API level for the primary architecture.
Test: TestVndkApexCurrent
Change-Id: Ie72a5beb9da432660d3fec5c520402224326f961
I49220cbec628f1508709741dc56b62aaac7786d9 attempted to allow
apexes to depend on native code whose min_sdk_version had been
increased to meet the minimum supported API level for a new
architecture. It wasn't quite right, as it assumed that the
primary architecture of the apex would be the newest, and
it applied to all dependencies, not just ones that were
specfiic to the new architecture. Move the checking into
cc.ShouldSupportSdkVersion, where it can be specific to an
individual architecture variant.
Bug: 250918230
Test: TestApexMinSdkVersion_MinApiForArch
Change-Id: I303cf485ba54b4c6bf63a9f9b49286ff9b2c9c83
Apexes for new architectures have to increase their minSdkVersion
to the minimum supported version for the architecture.
Bug: 250918230
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true nothing
Change-Id: I49220cbec628f1508709741dc56b62aaac7786d9
Fix panics in api_level.go and apex.go when using riscv64 as the target
arch.
Bug: 250918230
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true nothing
Change-Id: I85c7685f3d14fa2dc7ffbcdea7f490feca304ef7
Handling of API levels within Soong is currently fairly difficult
since it isn't always clear based on context what kind of API level a
given string represents, how much canonicalizing and error checking
the code receiving the string are expected to do, or how those errors
should be treated.
The API level struct does not export its raw data, so as to keep its
"constructor" private to the android package, and to prevent misuse of
the `number` field, which is only an implementation detail for preview
API levels. API levels can be parsed with either
`android.ApiLevelFromUser`, which returns any errors to the caller, or
`android.ApiLevelOrPanic`, which is used in the case where the input
is trusted and any errors in parsing should panic. Even within the
`android` package, these APIs should be preferred over direct
construction.
For cases where there are context specific parsing requirements, such
as handling the "minimum" alias in the cc module,
`nativeApiLevelFromUser` and `nativeApiLevelOrPanic` should be used
instead.
Test: treehugger
Bug: http://b/154667674
Change-Id: Id52921fda32cb437fb1775ac2183299dedc0cf20
