Currently, ApiLevelFromUser calls ReplaceFinalizedCodename(raw).
This function checks whether raw is in the getFinalCodenamesMap which is
equivalent to ApiLevelsMapReleasedVersion with an additional entry for current.
Since ApiLevelFromUserWithConfig already returned on the raw = "current"
we only care about ApiLevelsMapReleasedVersion and can avoid the unecessary
use of strconv.Atoi(strconv.Itoa(raw)) that calling ReplaceFinalizedCodename
ends up doing.
Also makes the function look more like the Bazel version in
build/bazel/rules/common/api.bzl
Change-Id: I8c03fc159d7f63298273624f030d1956e2307615
Test: m bp2build
When the branch is configured as something less than the max codename
(for example, right now AOSP is U but V is also in development), the
active codenames list will not include V.
Bug: None
Test: None
Change-Id: Ia22388a8ba94ff00d053acb33363c3cdce7677d0
This relands aosp/2457063. The original change broke T and U since those
branches still contain soong modules of type (kind+level). Those soong
modules have been cleaned up now
Test: Used go/abtd to test T and U branches with this change
Bug: 208456999
Change-Id: I0ef7933c055f88cb512a02108f1173e51156ef1c
This relands aosp/2457062. The original CL was submitted as part of a
stack that broke tm and udc. Those branches still contain soong modules
with min_sdk_version of type (kind+level).
Bug: 208456999
Test: m nothing on tm and udc (via go/abtd)
Change-Id: I10e8bea59cd5914d36b2c9539ee1556e55b82e53
This relands aosp/2470068. The original CL was submitted as part of a
stack that broke tm and udc. Those branches still contain soong modules
with min_sdk_version of type (kind+level).
Test: m nothing on tm and udc (via go/abtd)
Bug: 208456999
Change-Id: I8e013ec10530372f70f0ab0505b7eebeee2b360b
min_sdk_version signifies device version and does not need an sdkKind to
describe it fully. Update the type and cleanup existing usages. As a
side benefit, we also get better error handling since users can no
longer enter something like `public_30` as a valid min_sdk_version in bp
files
Will do a similar cleanup for targetSdkVersion and maxSdkVersion in a
followup CL
Test: m nothing
Test: no change in ninja files (this should be a no-op)
Bug: 208456999
Change-Id: Ie6ae7e267d093c5e4787e82685daaca1021d202e
These functions already exist on SdkSpec(kind+level) and are used for
computing the effective version for vendor modules compiling against
current or system_current which depends on the sdkKind
Create these functions for ApiLevel to support migrating MinSdkVersion
from SdkSpec to ApiLevel. Since the "api level" of vendor modules depend
on the sdk_kind as well, these functions will continue to exist on
SdkSpec.
Test: m nothing
Test: no diff in ninja files (this should be a no-op)
Bug: 208456999
Change-Id: Iee5a936e72b02b4fab9e457082d46fb8358eff16
InvalidApiLevel:
This will be used for error handling if a user provided api level is
not recognized
PrivateApiLevel:
This will be used to differentiate the api level of sdk_version:"" from
sdk_version:"current" or sdk_version:"<active_codename>" (all used to be
FutureApiLevel previously). This was not necessary previously since the
type of min_sdk_version was SdkSpec(kind+level). Since it had access to
kind, it could check that it was not SdkSpecPrivate
Test: m nothing
Change-Id: I628b443c34bf2ec258d947dfec09f38b126bc6bb
This reverts commit 5d80d895b6.
Reason for revert: The issue that broke the build the first time this was submitted has been fixed in ag/19125702. Also the errorprone build was added to presubmit for changes to these files so we should hopefully catch any other issues at presubmit now: cl/458501206
Change-Id: I80ca08df49c58a1ad70de917822301368d49fc67
This CL fixes a bug when Soong pass `-target` with a non-digit suffix in Clang. As mentioned in b/236753843, Clang's version parsing expects to see an integer in the target string so it ignores the
S suffix.
Test: m gwp_asan_crash_handler && make sure -target is aarch64-linux-androidS instead of aarch64-linux-android31
Test: go test -run ^TestNonDigitMinSdkVersionInClangTriple$ android/soong/cc
Bug: 236753843
Change-Id: I258ecc52083dbf3471d23cf310e0ad54440f1908
Bug: 215567981
Bug: 204776549
Test: m out/soong/.intermediates/frameworks/base/framework-minus-apex/android_common/lint/lint-report.xml, then check that that file doesn't have any of these warnings
Change-Id: I39aa2228474630c93250bf5833ac6bd9bbadcc7f
Most of the variable export code for cc modules can be re-used for
exporting variables for java modules. Refactor this code into a more
composable structure for reuse.
Test: build/bazel/bp2build.sh
Test: manual comparison of
out/soong/soong_injection/cc_toolchain/constants.bzl
with previous output
Change-Id: Ie5a6fee08cc888b7dc69c3e324e5c3f8aa269a8f
This CL turns the stubs.symbol_file and stubs.versions properties into
stubs_symbol_file and stubs_version attributes on the cc_shared_library
target. See associated build/bazel change on how these attributes are
used to generate stub libraries.
Bug: 207812332
Test: New tests
Test: CI
Change-Id: Ie23eafb9903a131d92ff4e251215e998cea0a763
When building from source the build uses the java system modules for
the public or module APIs as needed. However, previously when building
from prebuilts it would always use the public API. That difference lead
to build failures when building from prebuilts.
This change makes the selection of java system modules when building
from prebuilts consistent with the selection when building from
sources.
As API levels 30 and 31 (which are the only previous releases to
provide system modules) did not provide separate java system modules
for the module-lib API those levels always use the public APIs.
Bug: 204189791
Test: - before applying these change
m TARGET_BUILD_APPS=framework-connectivity
- build fails with compilation error due to missing module APIs
m sdk dist
cp out/dist/system-modules/module-lib/core-for-system-modules.jar prebuilts/sdk/current/module-lib/core-for-system-modules.jar
- apply these changes
m TARGET_BUILD_APPS=framework-connectivity
- build passes as expected
Change-Id: Id113ff014e7892b1009fbcaad89b1ae23a7c3b79
Checking sdk_version broke mainline code that compiles against a current
API level but needs to be able to run on an older API level.
Bug: http://b/187907243
Test: treehugger
Change-Id: If1192ef2809e39b043f0a384775b6c9e3a8bd619
... in preparation for making the handling of sdk versions consistent
across java and cc modules.
Bug: 175678607
Test: m
Change-Id: I598f0454bce9b7320621022115412fbe97403945
When a cc module is built against a stub, compiler passes version macro
of the stub lib. Version macro should be numeric, so codenames or
"current" should be mapped to numbers just like how ndkstubgen maps to.
* "current" -> future (10000)
* codenames -> look up api_level.json
* otherwise -> cast to int
Bug: 179329813
Test: m / soong test / manually check the output build.ninja
Change-Id: Ic0e1dd904984e161694a0b77fad5559c06a4462f
If we don't check "current", it won't be checked even in the finalized
branch.
If we don't check "preview", it should be done during the SDK
finalization. It'd be better done before the SDK finalization regarding
that setting min_sdk_version is to get approval from deps library owners.
Bug: 177833148
Test: m (soong tests)
Change-Id: I712b61cfe5a134fbb69c73956d26fb3a1e5c011e
The android.WriteFile rule takes careful escaping to produce the
right contents. Wrap it in an android.WriteFileRule that handles
the escaping.
Test: compare all android.WriteFile outputs
Change-Id: If71a5843af47a37ca61714e1a1ebb32d08536c31
apex_test.go wasn't listed in the Android.bp file, which allowed
it to bitrot. Make the API level methods take a PathContext
so that they can be called from a test using configErrorWrapper.
Also fix an int that was converted to a string.
Test: apex_test.go
Change-Id: I1ff87134c837bd5d344d22550baabde10d1b0b2e
The test case I removed is invalid. The codename has had its int
assigned, but the config claims it is not final.
If this ever does need to be supported it's just a matter of making
sure the Q -> 29 mapping (or whatever) in the finalized codenames map
in android/api_levels.go.
Test: treehugger
Bug: http://b/154667674
Change-Id: I4f42ec2fd4a37750519ee3937938a1c65b6bb1e8
Keeping the int constant around for now as FutureApiLevelInt because
it's still useful in places that haven't adopted ApiLevel yet for
testing if their non-ApiLevel API level is current or not.
Test: treehugger
Bug: http://b/154667674
Change-Id: I47a7012703f41fdeb56f91edf9c83afa93042deb
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
It has been wrong to split ALL_VERSIONS into exclusive two sets of
before/after TARGET_PLATFORM_VERSION.
And PLATFORM_VERSION_ALL_CODENAMES supports all *active* list of
non-finalized codenames.
Bug: 152960049
Test: m
Change-Id: I78ca88758998e440bea72ba2d56d90eea3ec99ae
Apex can use codenames like "Q", "R" for its min_sdk_version property.
Also, cc_library can use codenames for its stubs.versions.
Bug: 152655956
Test: vendor/google/build/build_mainline_modules.sh
Change-Id: I077ad7b2ac5d90b4c8708921e43846206f05ba70
