* changes:
Update min_sdk_version from SdkSpec to ApiLevel
Always include host variants in the sdk snapshot
Prework for migrating min_sdk_version from (kind+level) to (level)
Create EffectiveVersion* functions for ApiLevel
Create two sentinel api levels
build/make has several hardcoded references to these modules. In
preparation for switching between stubs generated from .txt files,
export these module names to Make. This prevents duplication of stub
selection logic in multiple places.
Test: TH
Change-Id: I5b1ef27aaea269d60aa7953787ea10d1b2a793f2
These hardcoded refs will need to be updated when we start using .txt
stub equivalent (single-tree/multi-tree). Instead of strewing this logic
all over the codebase, create a helper function that contains the
replacement logic. All other places should call this helper function
instead of calculating the name of .txt equivalent soong module by
itself.
(Will do a similar cleanup in build/make)
Test: no change in ninja file
Change-Id: I6bf999eb4aeaba6ac2a44b9016bae4ec8c79ce19
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 502da3987a.
Reason for revert: b/274195633
```
In file included from out/soong/installs-aosp_cf_x86_pasan.mk:134984:
In file included from out/soong/Android-aosp_cf_x86_pasan.mk:981696:
In file included from build/make/core/soong_cc_rust_prebuilt.mk:76:
build/make/core/base_rules.mk:342: error: packages/modules/Uwb/service/uci/jni: MODULE.TARGET.SHARED_LIBRARIES.libuwb_uci_jni_rust already defined by packages/modules/Uwb/service/uci/jni.
```
Change-Id: Ic1ea6969e54c23a7d126eb0fb47ab6f2e44ee965
Now that the json module is available in the cquery starlark execution
enviornment.
Bug: 245315355
Test: m nothing
Change-Id: Ie7c314e2f4e2ef4257bd84abc1add01ddb668f0b
When specifying --extra_toolchains=//prebuilts/clang/host/linux-x86:all, there is no control over the sort order of toolchains, which can result in a more generic toolchain being used rather than the most specific (and correct) toolchain.
Apparently, this flag is causing Bazel to drop some flags from CppCompile actions. This causes mixed-build's outputs different from Soong build. The mixed-build also generates different from Bazel build because we don't use the flag when using `b` to build the targets.
Test: Inspect differences in CppCompile actions from Soong's Bazel aquery handler and b aquery
Bug: 273995121
Change-Id: Id9e32c0cd12ab8577cd5b223ca9e19c982f3ae1f
These will only be provisional, but there are enough different groups
that want *something* to make a start on porting that it's probably
time...
Ignore missing dependencies in build-ndk-prebuilts.sh for now, because
various pieces (that the NDK doesn't care about) are still missing.
Bug: http://b/273792258
Test: build/soong/scripts/build-ndk-prebuilts.sh
Change-Id: I39202a953a73dc449a10a887d497d09079c43402
This is part of the changes needed to switch to jdk17 as the default.
Test: presubmits
Bug: 215230098
Change-Id: I4dad9f576c88bdc98f329a35fb8a1eb1527b1366
These are used to build com.android.neuralnetworks and
com.android.media.swcodec.
Bug: 273927900
Test: b build --config=android //frameworks/av/apex:com.android.media.swcodec
Test: b build --config=android
//packages/modules/NeuralNetworks/apex:com.android.neuralnetworks
Change-Id: Ia36d6e3419fb5034f1dbf410da738fcbf98d6874
Currently, non-apex variants of modules that are in apexes are not
exported to make unless they're apex_available to the platform. This
means that you can't `m` those modules directly.
However, there is a workaround in the apex androidmk implementation that
emits make rules for the removed modules, but just redirects them to
build the apex itself. We want to remove that, but one of the problems
with doing so is that you can no longer `m` many modules afterwards.
To fix that, unhide the apex's dependencies from make. To ensure they're
not installed, call SkipInstall() on them, and update SkipInstall() to
be more strict by setting `LOCAL_UNINSTALLABLE_MODULE := true`.
Bug: 254205429
Test: Presubmits
Change-Id: Ib971981559f3b642ce6be8890679e994e1b44be0
This CL adds a few things:
1) Populate the filesInfo struct with cquery'd information from an
apex's ApexMkInfo provider. This filesInfo is then used in
apex/androidmk.go to generate Make modules (soong_cc_rust_prebuilt.mk),
which are then used in packaging to generate zip files of symbols in $PRODUCT_OUT.
2) Make a list of dicts of primitives JSON-encodable.
3) Tests.
Bug: 271423316
Bug: 271423062
Test: presubmits
Change-Id: Iaa34f51044de310510e580d9cf1fe60bbef801c1
Add a flag that enables logic specific to multitree-build builds.
Bug: b/266730267
Test: treehugger, manual
Change-Id: Ia6f392525faa9d66bb6e0692b2a2e9c3b8493b0d
for java_library, java_binary, android_app & android_library
Change-Id: Ia8dec7e7d497eb41b2d8dcd8c44c3090d1d3b4bd
Bug: 271265771
Test: go test ./bp2build
