This metadata module will contain a flattened list of all the soong
modules contributed by this module to the rest of the build. This is
supported in V and above.
Bug: 326246905
Test: m art-module-host-exports
Test: unzip -p out/soong/mainline-sdks/art-module-host-exports-current.zip Android.bp | grep -A 15 apex_contributions_defaults
apex_contributions_defaults {
name: "art-module-host-exports.contributions",
contents: [
"prebuilt_art.module.api.annotations",
"prebuilt_dex2oat",
"prebuilt_dex2oatd",
"prebuilt_dexdump",
"prebuilt_hiddenapi",
"prebuilt_oatdump",
"prebuilt_profman",
"prebuilt_veridex",
"prebuilt_libartpalette",
"prebuilt_libartbase",
],
}
Change-Id: Iba43a9da5430adfc0a5fd9b5dc27b5d89c5eacb8
With roboleaf being cancelled, we don't need the api levels to be
present in starlark.
Bug: 315353489
Test: Presubmits
Change-Id: I21ea61ced00a5b0ae066a9ca99a88a512bf115ac
The runtime in S and above does not have the same constraints that
require the hiddenapi flags to be generated in a monolithic manner.
This CL restricts the verify_overlaps to pre S modules. This will
filter out hiddenapi signature discrepancies that do not require
any action.
Test: verify_overlaps diff with this change https://diff.googleplex.com/#key=xxB0ky93hZRn
Test: presubmits
Bug: 313672880
Change-Id: Ie626a6779fc924563bec90b6c1ab0c7e8b4b23c2
This change provides support for prebuilt incremental platform API (i.e.
API changes associated with a QPR, as opposed to a major dessert
releas).
This feature is provided via the existing prebuilt_apis module with the
introduction of a new attribute:
allow_incremental_platform_api
While typical platform prebuilt APIs are presumed to be under a
directory structure that follows the pattern:
<version>/<scope>/<module>.jar
<version>/<scope>/api/<module>.txt
Where <version> is limited to a single integer signifying the API level.
For modules where allow_incremental_platform_api is set to 'true' (false
by default) the pattern is the same, however <version> is presumed to be
of the form MM.m, where MM aligns with the existing API level and m
signifies the incremental release (e.g. QPR).
Bug: b/280790094
Test: platform build check with both incremental & non-incremental API
cd build/soong && go test ./java
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:eee6995093485497bc29cdce01c2a86765ffb4eb)
Change-Id: I67e293006ccfa210d0dcc0a294db894632f1b6cb
Instead of exporting it to soong_injection.
Bug: 279095899
Test: m nothing
Change-Id: I7b93af233b7450848a475512b5f5682ece773c09
Merged-In: I7b93af233b7450848a475512b5f5682ece773c09
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
