Currently the product variable that is controlled by
APEX_GLOBAL_MIN_SDK_VERSION_OVERRIDE only overrides apexes, but it
doesn't apply to android_apps. This commit allows android_apps which set
updatable: true in their Android.bp to have their min_sdk_version be
overriden by this product variable.
Bug: 295311875
Test: go test
Change-Id: If3cb82a17cae4553b577dd1a4637ee13c3c95302
The core problem I am trying to solve is making sure that stub
libraries in Bazel have a single apex available. In Soong, this will be
enforced using some graph walk which is not easy to port to Bazel.
However, we might need to revisit this when we build the enforcement
mechanism in Bazel. We likely need a `test_for` on the top level
apex_test Bazel rule so that the test apex is _allowed_ to link against impl
of the library it is trying to test.
(This CL retricts this to cc_library, I can expand this to other modules
if this is the right approach.)
Bug: 277651159
Change-Id: Iaeec22c5626df79a33785c766ed29102b1da403e
SortedUniqueStrings and FirstUniqueStrings dedupes repeating elements
and returns the deduped list. Currently, it also modifies the input list
in-place, which causes non-determinisitc failures like b/275313114
Operate on a copy of the input so that the input remains untouched.
SortedUniqueStrings is O(NlogN) and FirstUniqueStrings is ~O(N), so
creating a copy (O(N)) should not result in major performance regressions.
Numbers for this single unit test:
```
go test . -run TestStubsForLibraryInMultipleApexes -v -count 1000
Before: 174s
After: 172s
```
Test: go test ./android
Test: go test . -run TestStubsForLibraryInMultipleApexes -v -count 1000
Change-Id: Id859723b2c2ebdc0023876c4b6fabe75d870bad7
Modifying the list in-place causes some non-determinism.
Test: go test ./cc -run TestStubsForLibraryInMultipleApexes -count 1000
Bug: 275313114
Change-Id: Ia2519e146d97667ad5900cf68ab9935fcbaf08a4
If any of apexes in apex_available is an apex_test, then that name will
be propagated down from that apex to each apex variant. This metadata
will be used to enforce that stub libraries cannot have more than one
apex_available.
This logic is necessary so that bp2build can select the correct
stub/impl.
(To avoid replicating this complexity in Bazel, we should consider
dropping the test apexes in Bazel BUILD files, next CL)
Bug: 277651159
Test: go build ./apex
Change-Id: I63617c1dc2a2d5c9cd7758c416fec7b4db1f10a7
go/Android.bp mentions that ["//apex_available:platform"] is the
default, but currently it was []. This change does not create any
additional module variants.
(Noticed this for libz, I was expecting its apex_available to be
platform and not an empty list)
Test: TH
Change-Id: I9af06f813b1a1d7b716939874f469bd2e1ce4d14
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
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
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
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
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: Ib094feb2c437ad50d8319c58caa997759e7ce32f
For now, bypass apex available check for native shared libs used by DCLA
apexes, for the long term, created b/248601389 to create AOSP version of
DCLA and mark necessary native shared libs available to this AOSP DCLA apex.
BUG: 239679485
TEST: local build of DCLA modules, no apex_available issue found
Change-Id: Ie08d555177bf19ec7c57009b798a41ce454fdeda
Also remove the soong hack that allowed us to build during the
transition
Bug: 243054261
Test: build + TH
Merged-In: I60bac1ec687f03a38f38240969a1c38a8e5bf92c
Change-Id: I60bac1ec687f03a38f38240969a1c38a8e5bf92c
Also remove the soong hack that allowed us to build during the
transition
Bug: 243054261
Test: build + TH
Change-Id: I60bac1ec687f03a38f38240969a1c38a8e5bf92c
The first hack has been introduced to facilitate the creation of the
com.android.btservices apex without the need to upload 100+ cl close to
the release date.
We now want to delete com.android.bluetooth apex and replace all the
apex_available rules to target the new apex name
It will be way much easier to do this in separate CL and without forcing
us into a single topic.
Bug: 243054261
Bug: 245214856
Test: Build
Change-Id: Ia03698db839db4684871eb38c088f88d6bdcba4b
(cherry picked from commit 2ad6e84d60)
Merged-In: Ia03698db839db4684871eb38c088f88d6bdcba4b
The first hack has been introduced to facilitate the creation of the
com.android.btservices apex without the need to upload 100+ cl close to
the release date.
We now want to delete com.android.bluetooth apex and replace all the
apex_available rules to target the new apex name
It will be way much easier to do this in separate CL and without forcing
us into a single topic.
Bug: 243054261
Test: Build
Change-Id: Ia03698db839db4684871eb38c088f88d6bdcba4b
This hard-coded list causes inconsistent behavior regarding -target
triple and _ANDROID_APEX_MIN_SDK_VERSION_ macro for native modules.
Bug: 158059172
Test: m
Merged-In: Iae3ecb3bfaefc2ee73ed38a9268c68b6673f30c5
Change-Id: Iae3ecb3bfaefc2ee73ed38a9268c68b6673f30c5
(cherry picked from commit 870ab9c0f78327d92a871ac58c0337db8ae92245)
Set min_sdk_version/apex_available for modules used by
com.android.permission APEX.
Bug: 147364041
Bug: 158059172
Test: m
Change-Id: I93ff72ed765354d44a2ccb5105b5f2820f0358f5
Hard-coded min_sdk_version is not necessary for kotlinx-* modules
because they are already marked by updater script.
Bug: 158059172
Test: m nothing
Change-Id: I42cf26c9390244f93059af68027cca4f8518a828
