There are a couple of instances in apex/ and java/ that rely on the naming
convention that the jars exported by prebuilt apexes follow the name of
the java_sdk_library_import, minus the prebuilt_ prefix. With muliple
module sdk prebuilts in trunk stable, this naming convention might not
be valid. Use `source_module_name` instead.
```
prebuilt_sscp_fragment {name: "", contents: ["service-foo.v2"]}
java_import {name: "service-foo.v2", source_module_name: "service-foo"},
```
We should use service-foo and not service-foo.v2 because
1. The prebuilt apex contains service-foo.dex
2. PRODUCT_*JARS will contain service-foo and not service-foo.v2
For clarity, this CL does not drop the current mechanism where prebuilt bcp
fragments create a dependency edge to prebuilt java or java_sdk_library
imports. There is still some discussion around whether we can remove
that completely (b/320711431). If we were to do that, then the
Android.bp files will become
```
prebuilt_sscp_fragment {name: "", contents: ["service-foo"]}
```
Bug: 322175508
Test: Added a unit test
Test: In internal, lunch cf_x86_64_only_phone-next-userdebug && m
nothing # .ninja files identical
Test: In internal, created a parallel set of v2 prebuilts of
java_sdk_library_import and prebuilt_bcp_fragments for adservices && m
nothing # build passes
Change-Id: Ia899d75e826fa1a559368d706eaa65835f748d40
This CL is the java_system_modules_import equivalent of aosp/2928483.
With trunk stable, we will have multiple versions of art prebuilt apex
in the tree. Each art apex will contribute its own module sdk, i.e. its
own prebuilt system_modules to the build. This CL introduces a mechanism
to selelect a specific version of prebuilt system modules using
apex_contributions.
Implementation details: Create a new source_module_name property to
identify the root module. rdeps referring to the root module will get
redirected if necessary.
Bug: 322175508
Test: Added a unit test
Change-Id: I9f885ffa5afea96d2e6ce077264d3b207ed7e80d
Bug: 318567881
Test: CIs
Test: add a Android.mk file in a blocked directory(e.g. cts/) and 'm nothing', an error message should be displayed and build process is stopped.
Change-Id: I3e1f63a13a20f77576b0e7424304a661f144df53
ANDROID_PUBLIC_STUBS currently has multiple usages in the build, in
multiple .mk files.
Instead of modifying the current functionality of ANDROID_PUBLIC_STUBS
by replacing its value from "android_stubs_current" to
"android_stubs_current_exportable", this change introduces
ANDROID_PUBLIC_EXPORTABLE_STUBS, which evaluates to
"android_stubs_current_exportable" and used only when generating the
`full_target` in `development/build/Android.mk`.
Test: patch in git_main, lunch aosp_arm-ap31-eng && m sdk dist && inspect android.jar outputs
Bug: 323261972
Change-Id: Ic2b03a5a4afdefb459d89f8104916446599eaf31
Soong dumps BOARD_VNDK_VERSION to check if devices use VNDK when VNDK is
first introduced. However, VNDK is fully used from all device so this is
no longer required. Also, BOARD_VNDK_VERSION property is expected to be
deprecated along with VNDK deprecation. This change removes
BOARD_VNDK_VERSION from dump variable target.
Bug: 316829758
Test: AOSP CF build succeeded
Change-Id: I2fdb92a0e03629366a515d3b6705f7a7db0c1159
This CL is the java_sdk_library_import equivalent of aosp/2928483.
With trunk stable, we will have multiple apex prebuilts in the tree.
Each apex prebuilt will have its own module sdk. This means that it is
possible to have mutliple versions of `framework-foo` in the tree. This
CL introduces a mechanism to select a specific versioned
java_sdk_library prebuilt.
Implementation details
- Add a `source_module_name` property to java_sdk_library_import. This
will identify the source equivalent of the jsl in packages/modules.
This used to be implicit - i.e. the name without the prebuilt_ prefix.
With multiple prebuilts, this has to become explicit.
- Set appropriate `source_module_name`(s) in the dynamically created
child modules. e.g. the source_module_name on sdklib.v1.stubs and
sdklib.v2.stubs will both be sdklib.stubs, assuming
`source_module_name` on the top-level jsl_import is sdklib
- Add a private Created_by_java_sdk_library_name property to java_import
and prebuilt_stubs_sources modules. This will be used to idenfity the
top level java_sdk_library_import that was used to create these child
modules. This is necessary because java_sdk_library_imoprt is a macro
that creates 1:many modules. However, to avoid toil, only the
top-level java_sdk_library_import will be listed in
`apex_contributions`. This new property will be used for
source/prebuilt selection in android/prebuuilt.go
- Rename BaseModuleName in commonSdkLibraryAndImportModule to
RootLibraryName. This is necesssary because the former is now reserved
to identify the source equivalent of a prebuilt module (maybe we
should rename it?)
Bug: 322175508
Test: Added a unit test
Change-Id: If6aa6b0e939a07f8263874941413908383c81a78
I want to be able to use certain characters to separate a namespace
from a variable, but currently it's possible for soong config namespaces
and variables to have any character in them.
Restrict them to just identifiers, which should cover all of our
existing usages.
Bug: 323382414
Test: Presubmits
Change-Id: I6d55dd3378ac4d257efde450189b81a4aa3932c3
this.teams_for_mods uses a dictionary and `range` yields a
non-deterministic ordering. This would cause all_teams.pb to be
non-determinisitic. Since this file is created during Soong analysis, it
would cause the .ninja file to also be non-deterministic.
Use SortedKeys to do the iteration instead.
Test: go build ./android
Test: m nothing a couple of times and checked that the .ninja files are
identical
Change-Id: Ife2d2520d118ef25639f86390912d98b5f057655
The aconfig files are collected by visiting the direct deps of the
module. VisitDirectDeps does not guarantee ordered traversal. To prevent
non-determinism in the generated ninja file, sort the inputs.
Test: go build ./android
Change-Id: Ic67fc0859bf18de62b6297ed502d1d495cc3a780
Similar with aosp/2897612, rename LOCAL_USE_VNDK into
LOCAL_IN_VENDOR or LOCAL_IN_PRODUCT to make variable useful from
VNDK deprecation.
Bug: 316829758
Test: AOSP CF build succeeded
Change-Id: If7bead24add014ed9e0e9e1d265b0199b911be89
In order to use soongdbg, you must run analysis with GENERATE_SOONG_DEBUG=true set
in the environment.
Test: GENERATE_SOONG_DEBUG=true m nothing ; soongdbg ...
Change-Id: If43676fe2784f05cd87c0ecb4a46ab676b91023f
