The availability of these soong modules to com.android.wifi has
been made explicit in Android.bp files
Bug: 281077552
Test: m nothing
Change-Id: I6ac447ffe4b477a49064ed0ec4081e087f0edf9d
This is a followup cleanup for aosp/2876754 and replaces panic with
ctx.ModuleErrorf. The latter creates a more expressive build error.
Implementation details
- export moduleErrorf interface from build/soong/android. This minimal
interface will be used as a parameter for `DexJarBuildPath`
- Add ModuleErrorf to the function signature of DexJarBuildPath. This
parameter only gets used for Import and SdkLibraryImport structs.
These two can have duplicate deapexer definitions, and ModuleErrorf
will be used to report that error
- Create a minimal implementation of `ModuleErrorf` in tests of java and
apex
Test: m nothing --no-skip-soong-tests
Change-Id: I0febec651f40c3f04deb957e64133c94b80fbd78
Current CC/Rust Image variations are generated with target VNDK version.
However, this is no longer valid if VNDK is deprecated. This change
generates image variation without version ("vendor", "product") if VNDK
is deprecated.
Bug: 316829758
Test: m nothing --no-skip-soong-tests passed
Test: aosp_cf_x86_64_phone build succeeded
Change-Id: I2387ed8a2632bfd9462621f882a947695ae1653d
The availability of these soong modules to com.android.mediaprovider has
been made explicit in Android.bp files
Bug: 281077552
Test: m nothing
Change-Id: I4c1e751a2a912271049bd241a01168685716bf9c
The availability of these soong modules to com.android.tethering has
been made explicit in Android.bp files
Bug: 281077552
Test: m nothing
Change-Id: Ib96d5ecb8518628fda8c474b10e443abacc9bc21
hiddenapi processing require boot jars from apexes to determine the full
set of methods available at runtime.
When building with prebuilts, this comes via
java_import/java_sdk_library_import, which acts as a hook for
prebuilt_apex/apex_set. If we have multiple apexes in the tree, this
hook becomes 1:many. This CL prepares platform_bootclasspath to select the right
deapexerd .jar files when mutliple prebuilts exist.
Implementation details
- Create a dependency edge from platform_bootclasspath to
all_apex_contributions (DepsMutator)
- For every boot jar, query all_apex_contributions to get the path to
dexjar file (GenerateAndroidBuildActions)
Some other important details
- This CL does not drop the old mechanism to get the dex file (i.e. by
creating a dep on java_library). Once all mainline
modules have been flagged using apex_contributions, the old mechanism
will be dropped
- This CL has a functional change when building with source apexes. At
ToT, the unecoded hiddenapi dex jar is used for package check and
generating the monolithic stub file. After this change, the hiddenapi
encoded file will be used for these operations.
This should be fine since the
package and dex signature do not change across the encoded and
unencoded dex file. In fact, we already have a split today. When
building with prebuilts, we use the encoded dex file. When building
with source, we use the unecoded dex file.
Test: Added a unit test
Test: Manual testing in internal described below
- lunch cf_x86_64_phone-next-userdebug
- flagged com.google.android.adservices using apex_contributions
- aninja -t commands out/soong/hiddenapi/hiddenapi-stubs-flags.txt # no
diff before and after
Bug: 308790777
Change-Id: I72c70f0ae1b587679203ea254c9c12a48e7aa782
The implicit //apex_available:anyapex seems to be unused, so we can drop
it
Bug: 281077552
Test: m nothing
Change-Id: I66fef50901bfd19237a9ef96b169ecefa01d76b9
hiddenapi and dexpreopt require boot and system server jars from apexes.
When building with prebuilts, this comes via
java_import/java_sdk_library_import, which acts as a hook for
prebuilt_apex/apex_set. If we have multiple apexes in the tree, this
hook becomes 1:many. This CL prepares dex_bootjars to select the right
deapexerd .jar files when mutliple prebuilts exist.
Implementation details
- Update prebuilt module types (prebuilt_apex/apex_set) and source
apexes to set a map of
library name to dex jar path on host.
- dex_bootjars will access the path of the .dex jar on host via the
provider. These then
copied/installed to the right locations.
This CL does not drop the old mechanism to get the dex file (i.e. by
creating a dep on java_library). Once all mainline
modules have been flagged using apex_contributions, the old mechanism
will be dropped
Bug: 308790457
Test: git_master-art-host:art-gtest https://android-build.corp.google.com/builds/abtd/run/L21500030000926533
Test: git_main:art_standalone_dexpreopt_tests https://android-build.corp.google.com/builds/abtd/run/L99000030000891212
Test: Added a unit test that checks that the right .jar is selected
when multiple prebuilts exists
Change-Id: I6ef94135b9303a35135810930af4b641df13a583
Generating boot image requires a .prof file provided by the ART apex.
When building with prebuilts, this comes via the
prebuilt_bootclasspath_fragment module, which acts as a shim for
prebuilt_apex/apex_set. If we have multiple prebuilt apexes in the tree,
this shim becomes 1:many. This CL prepares dex_bootjars to select the
right .prof file when multiple prebuilts exist.
Implementation details
- Update deps mutator of dex_bootjars to create a dep on
all_apex_contributions. The latter contains information about which
apex is selected in a specific release configuration. dex_bootjars
will create a dependency on the selected apex in a postdeps phase
mutator.
- All apex module types (apex, prebuilt_apex and apex_set) will set a
provider that contains info about the location of the .prof file on
host
- dex_bootjars will access the provider of the selected apex to get the
location of the .prof file
This CL does not drop the old mechanism to get the .prof file (i.e. by
creating a dep on {prebuilt_}bootclasspath_fragment). Once all mainline
modules have been flagged using apex_contributions, the old mechanism
will be dropped
Bug: 308790457
Test: Added a unit test that checks that the right .prof is selected
when multiple prebuilts exists
Change-Id: I40fdb21416c46bed32f6ff187ce5153711ec2c69
FindDeapexerProviderForModule raises an exception if multiple apexes in
the tree has an export dep on the java module. In prepartation to
support multiple prebuilts, move this error check out of
FindDeapexerProviderForModule and into rdeps. i.e. raise an exception
only if an rdep calls DexJarBuildPath
- This should be a no-op for now.
- In the short-term future, a java import module will be allowed to have
multiple deapexers. An error will be raised if anyone actually tries
to depend on the dexjar
- In the long-term future, this function will be removed. All processing
will be done at the prebuilt apex level and not at the prebuilt java
library level
Since this check now happens in the moduleCtx of rdeps, add some
additional props to unit tests to ensure that it does not exit early on
unrelated validation checks (e.g. hidden_api prop is not set)
Test: go test ./apex ./java
Bug: 308790457
Change-Id: I3323d993c1ea8f43305834cae8e65b6fe41dfefd
dexpreopt of apex system server from prebuilts involves three soong
modules
1. prebuilt_apex / apex_set
2. an internal deapexer module created by the prebuilt apex
3. java_import/java_sdk_library
(3) acts as a shim for the deapexer to set the dexjar extracted from the
prebuilt apex. This methodolody requires a 1:1 correspondence across the
three modules
This breaks down when we have multiple versions of the same prebuilt
apex in the tree. In preparation for this, move the dexpreopt
processing from (3) to (1). Each prebuilt_apex will create the necessary
rules for dexpreopting the jars deapexed from itself. In the future,
apex_contributions will be used to pick which service-foo.{odex|.vdex} to
install depending on which prebuilt apex is selected.
Implementation details
- Embed dexpreopter in prebuiltApex structs so that this module type can
register the dexpreopt rules. Since a single apex can have multiple
system server jars, this also requires creating an additional scope in
dexpreopt.go to prevent name collisions
- Add the dexpreopt modules as required in initApexFilesForAndroidMk
- Add the depreopt modules to androidMk in AndroidMkEntries. Drop the
equivalent from java_import and java_sdk_library_import
Bug: 308790457
Test: existing soong unit tests
Test: lunch cf_x86_64_phone-next-userdebug && m out/target/product/vsoc_x86_64/system/apex/com.google.android.adservices.apex
Test: Verified that the above command installs
/out/target/product/vsoc_x86_64/system/framework/oat/x86_64/apex@com.android.adservices@javalib@service-adservices.jar@classes.{odex|vdex} and the equivalent files of service-sdksandbox
Test: presubmits
Change-Id: I01cea8956d2857fb864b415e73d3d2686d069b5e
Convert all of the callers of ModuleProvider/ModuleHasProvider to use the
type-safe android.SingletonModuleProvider API.
Bug: 316410648
Test: builds
Change-Id: I6f11638546b64749e451cebbf33140248dc1d193
Convert all of the callers of OtherModuleProvider/OtherModuleHasProvider
to use the type-safe android.OtherModuleProvider API.
Bug: 316410648
Test: builds
Change-Id: Id77f514d68761a262d9ea830a601dbed804bbbe5
Convert all of the callers of Provider/HasProvider to use the type-safe
android.ModuleProvider API.
Bug: 316410648
Test: builds
Change-Id: I73479de1625fa2865b6c73444cd477e50d56dc5a
Convert all of the callers of SetProvider to use the type-safe
android.SetProvider API.
Bug: 316410648
Test: builds
Change-Id: If58f4b5355264ddab2045bc3591a4eac19cd58fc
Convert all of the callers to NewProvider and NewMutatorProvider
to use a generic type parameter instead of an example object.
Bug: 316410648
Test: builds
Change-Id: Ic9cdafc87336e26730d3fd596df05de0e7267542
Using generics for the providers API allows a type to be associated
with a ProviderKey, resulting in a type-safe API without that doesn't
require runtime type assertions by every caller.
Unfortunately, Go does not allow generic types in methods, only in
functions [1]. This prevents a type-safe API on ModuleContext, and
requires moving the API to be functions that take a ModuleContext as
a parameter.
This CL creates the new API, but doesn't convert all of the callers.
[1] https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#no-parameterized-methods)
Bug: 316410648
Test: builds
Change-Id: I3e30d68b966b730efd968166a38a25cc144bd6de
Also remove the code to package aconfig files for transitive
dependencies since those files should have already been included in the
direct dependencies.
Bug: 311173471
Test: Unit tests
Change-Id: I25637af9381f71a78b70a8de9894618188c9735d
Remove the ConvertWithBp2build implementations from all the module
types, along with the related code.
Bug: 315353489
Test: m blueprint_tests
Change-Id: I212672286686a318893bc7348ddd5a5ec51e77a7
Passing the list of all transitive aconfig files to Make causes extra
Kati analysis runs when dependencies are changed in Android.bp files.
Since Make is going to merge them anyways, merge them per-module and
pass a single aconfig file to Make for each module.
Fixes: 313698230
Test: m out/target/product/vsoc_x86_64/system/etc/aconfig_flags.pb
Change-Id: Ifde4826bc93bc06e40338f72b4cb39eed26ca08d
This is a common mistake when creating a vendor apex. They often try to
list all dependencies. Adding an LLNDK results in putting a stub library
in APEX, which simply doesn't work.
This change prevents stubs from being added to APEX.
Bug: 314033460
Test: go test ./apex
Change-Id: Ic3365047028d9ab6f06992d52aece5a3890177bb
This is to handle libz special case. libz has stubs but not an LLNDK.
So, libz.vendor should be treated as non-stub-providing libraries and
Vendor APEX should bundle it if it's used by its contents.
libz will set no_stubs for vendor/product variants.
Bug: 313806237
Test: go tests ./apex/...
Change-Id: I10759d7073838909126f8bfe87654f11aa02fd32
The next CL will need a TestContext parameter in
ContentFromFileRuleForTests in order to retrieve the file rule contents
from the Config. Add it and update all the tests that use it in order
to simply review of the next CL.
Bug: 306029038
Test: go test ./...
Change-Id: Ia4b4c9854017ea3472fa2f8ba42cf7f72720496e
All the necessary license data is already propagated through the license
metadata file, and the entries in Android-${TARGET_PRODUCT}.mk are not
used. Remove them, which should both reduce the size and parsing cost
of the Android-${TARGET_PRODUCT}.mk file and also removes a variable
that changes when dependencies are added or removed, which will
eventually allow running kati less often.
Bug: 309006256
Test: No change to out/Android-aosp_cf_x86_64_phone.ninja
Change-Id: Idfeb6fd10d77497ca274f8e74fe8e994ce1cafe6
Add a method to DataPath that converts it to the relative install path
in preparation for adding additional complexity to DataPath.
Bug: 311428265
Test: builds
Change-Id: I65b06238aafda2db72c6a253744a3087976451cd
Installed files should only depend on other installed files, change
the deps arguments of the ctx.Install* methods from Paths to
InstallPaths.
Bug: 311428265
Test: builds
Change-Id: I1ebef60a943bdbe907744cc43aa985371ac56d32
Merged-In: I1ebef60a943bdbe907744cc43aa985371ac56d32
To support trunk stable, file_contexts files should be processed before
creating APEX images. That means that file_contexts may be under out/.
This change relaxes the path check so we can use Soong-generated
file_contexts, not only the real source file_contexts. Of course the
restriction that modules should be under system/sepolicy is still
enforced.
Bug: 306563735
Test: build with generated file_contexts; see virt apex
Change-Id: I3aa368b338141d4826fc8622e1c8d2838bfd8484
The jdepsGeneratorSingleton can get the module path directly, it doesn't
need to be collected by each module type that implements IDEInfo. Fixes
module types (like android_library) that didn't reach the code that
collected the path.
Bug: 309835196
Test: out/soong/module_bp_java_deps.json contains path for ExtServices.core
Change-Id: If8cb81b4f708e0367f156ade164bee253bf53492
It was 'vendor_apex_metadata_file', but root directories can be simply
labelled as 'vendor_file' so that linker can resolve paths in vendor
apexes.
Bug: 310528686
Test: m blueprint_tests
Change-Id: I689b23efccb7be61980e791e185fcef28a76d9bc
These soong modules list the relevant apex_available values explicitly
in Android.bp files
Test: m nothing
Bug: 281077552
Change-Id: I7ec8e0f9d7ab7cbfb881d59d3e5d2bb8a2975ff8
And com.android.appsearch since the lone entry in the map specifies
com.android.appsearch in its Android.bp file explicitly
Bug: 281077552
Test: m nothing
Change-Id: I0b7e37f0b6ace21d37c8b0077bacf83b49318744
apex.unwanted_transitive_deps can break the APEX when any of listed deps
is actually needed. To avoid that, a new validation is added to see if
"unwanted" deps are actually not used by any ELF files in the APEX.
The new validation runs only for non-test apexes with
unwanted_transitive_deps set because test apexes can be broken
intentionally.
Bug: 295593640
Test: m com.android.virt
Change-Id: I29a3f7ef76b59594a08cfacca4811f16bf7172cc
Before this change, the build system had special logic to find mainline
BCP jars and copy them to a special location for app dexpreopt. This
logic doesn't work on `next`. In fact, we don't need this logic anymore.
Since we are now generating the mainline boot image extension, we can
reference the inputs of the mainline boot image extension, which are
exactly the mainline BCP jars needed for app dexpreopt.
Bug: 309302263
Test: atest art_standalone_dexpreopt_tests (on next)
Test: m --no-skip-soong-tests nothing
Change-Id: I055018ffbc5d7e5678f305e65a7f1c7e73bf3b99
It can be used as a workaround when the current build system adds more
than necessary to APEX.
Bug: 263308515
Bug: 295593640
Test: m blueprint_tests
Change-Id: Ib59c4ac59e6128b3d112b97876e9e2d1e6ec4211
