This provider contains information about the contents of an apex and is
set during the post deps phase of top-level source and prebuilt apexes.
java.dexpreoptDisabled needs to distinguish between platform and apex
variants of a library to prevent creating duplicate ninja rules. It does
so by looking at ApexInfoProvider. This provider gets set on the ctx of
the java_library being dexpreopted.
In case of prebuilts, these rules are being moved to the top-level
prebuilt apexes. Move ApexInfoBundleProvider from apex to android so
that java.dexpreoptDisabled can consume this provider without running
into a golang circular dependency. (java.dexpreoptDisabled will use this
provider in the next CL of this stack).
Test: go build ./android ./apex
Change-Id: I665abd9d0591eeb17b273cc822beb20690e6af09
Aconfig file dependencies are module-independent, and properly part of
ModuleBase.
Bug: b/308625757
Test: manual
Change-Id: I38c5907d1671cc69bb198345201316ae781fdc9f
Convert coverageMutator to a TransitionMutator as a step towards
variants-on-demand.
Bug: 319288033
Test: coverage_test.go
Test: treehugger coverage builds
Change-Id: Ic50c0040dea8b42c36b5d784221daa00b7b0d379
(This was missed in aosp/2876756, which copied only the bcp jars)
This hardcoded location is used by dex2oat to compile the dexpreopt
artifacts. The copy rules are currently generated by java_(sdk)_library
for source builds, and their prebuilt counterparts in prebuilt builds.
After this change, the copy rule will be bifurcated between source and
prebuilt builds
1. For source builds, it will come from java_(sdk)_library
2. For prebuilt builds, it will come from the top-level prebuilt apex.
Since there can be multiple prebuilt apexes in trunk stable,
HideFromMake will be used to determine which deapexed jar to copy.
The bifurfaction is expected to be temporary. It is needed for now since
the `apex_contributions` which will be used for source vs prebuilt
selection have not been populated completely.
Test: Added a unit test
Test: Presubmits
Test: git_master-art-host:
art-gtest (https://android-build.corp.google.com/builds/abtd/run/L40800030001459791)
Test: git_main:art_standalone_tests
(https://android-build.corp.google.com/builds/abtd/run/L09000030001463855)
Bug: 308790457
Change-Id: I3105d3b3a7e5c41cb601d07806f4ea483a61b50a
hiddenAPIFlagFileCategory used to contain function pointers, and is
used in a provider. Providers must be serializable for incremental
soong support, so the function pointers must be removed.
Refactor hiddenAPIFlagFileCategory into a simple int.
Bug: 322069292
Test: m nothing --no-skip-soong-tests
Change-Id: I2bd50fa1b59979f30869b405314cbef16ee345f1
strict updatability linting has been disabled for a while now.
In the process of re-enabling it, we need to allowlist all the apexes
that have violations.
Bug: 320698986
Test: Presubmits
Change-Id: I96501bc120d8127cb3675ecbee088ea887fabbc1
aosp/2876754 missed adding error handling to one of the places which
consumes the dex jar deapexed from prebuilt apexes. This CL ensures that
when we have multiple prebuilt apexes _without_ flagging, the hiddenapi
processing code emits a more descriptive error "Multiple deapxers..."
rather than a cryptic error "<module> does not provide a dex jar"
Test: m nothing --no-skip-soong-tests
Change-Id: I80849fa7cca17d724ac53c94bb353b169175ee28
The availability of these soong modules to com.android.runtime has
been made explicit in Android.bp files
One exception is libz. Making apex_available explicit has some subtle
implications on stub/impl selection which breaks coverage builds.
Bug: 281077552
Test: m nothing
Change-Id: I6db7db6dfcb5c468ca68c3e166fe79b9356c4fa8
This change is to fix more misc issues to enable Soong without VNDK
version. This change contains
* Update properties in generated Android.mk
* Update VNDK APEX build to work without VNDK version
Bug: 316829758
Test: AOSP Cuttlefish build succeeded
Change-Id: I10f3c798299afe2d539ec3426b8e2b6068a158f6
* changes:
Copy exportable artifacts to module sdk snapshot
Enable hiddenapi check for exportable stubs
Add defaults support for bootclasspath_fragment module type
This change modifies the dependencies of the hiddenapi to always depend
on the exportable stubs, instead of the currently utilized everything
stubs.
To support this, the full api surface exportable stubs are defined in a
separate change at the `frameworks/base` project. Note that the full api
surface exportable stubs are only used for the hiddenapi purpose, and
`sdk_version` continues to utilize the currently existing everything
stubs.
Currently, this feature is hidden behind the build flag
"RELEASE_HIDDEN_API_EXPORTABLE_STUBS". This feature will be fully
enabled once metalava fully supports handling of the flagged apis.
Test: ENABLE_HIDDENAPI_FLAGS=true m
Bug: 317426356
Change-Id: I109b7cd27b20ceffcdf1766ab8106b0c276be2b3
Every module belonging to a single mainline module family will be
hidden from make, except the one which has been flagged using
apex_contributions
Details
- Introduce a new `source_apex_name` property to prebuilt_apex and
override_apex. This property will be used to identify the source
equivalent of a prebuilt soong apex module.
- Create an N-ary tree from source to prebuilt(s). The tree wil be
rooted at the source module.
- In a subsequent mutator, visit every node in the tree(s). Query
apex_contributions and store the handle of the node which is "active"
(if any)
- In the same mutator, do another pass over the tree. Invoke
`HideFromMake` on every node which is not "active". The two-pass
approach is needed PrebuiltSelectionInfoProvider does not know about
the inter source-prebuilt dependency, this dependency can only be
known by doing a graph walk of the N-ary tree.
Some tangential implementation details
- Each prebuilt apex has an internal deapxer module that is responsible
for generating the deapex ninja rules. The name of this internal
module uses the BaseModuleName (without the prebuilt_ prefix). Since
we can have multiple prebuilt soong modules in trunk stable, change
this to follow the name of the prebuilt module in order to avoid name
collisions. Update existing unit tests accordingly
Bug: 316179314
Test: go test ./apex -run TestInstallationRulesForMultipleApexPrebuilts
Test: m nothing --no-skip-soong-tests
Test: presubmits
Change-Id: I58aa99d5e6a9859954614e6db9a8e9e2e581642d
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
This cl adds support for prebuilt_etc types in
ApexNativeDependencies, this enables us to include rialto only in
the arm64 environment.
Test: atest sign_virt_apex_test
Bug: 279886264
Change-Id: If25e726721ed6867858880bc6907a0a3c0cb252d
UseVndk is a function to check if the module can use VNDK libraries, but
this function was also used to check if the module is installed in the
treblelized partition (vendor or product). As of VNDK deprecation,
UseVndk funtion will return false even when the module is installed in
vendor / product partition, so we need a separated function to check
this. This change introduces a new function 'InVendorOrProduct' which
replaces UseVndk based on its usage.
Bug: 316829758
Test: m nothing --no-skip-soong-tests passed
Change-Id: Ic61fcd16c4554c355f6005894a4519b044b27fe5
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
Instead of listing all apexes in the source tree, now each apex emits
its own fragment for apexkeys.txt, which is pointed by
LOCAL_APEX_KEYS_FILE. Makefile collects apexkeys.txt from installed apex
files. This is to avoid listing unrelated apexes (not installed,
testdata, unexported namespaces, etc.)
Bug: 304914238
Test: m apexkeys.txt
Test: m blueprint-tests
Change-Id: Iefbe6e486cb418955584ad1a282455307e90be95
apexkeys.txt should list the installed apexes. But for now it lists all
apexes in the source tree. To fix this, each apex(or prebuilt/apexset)
will generate its own apexkey info and they'll be merged into a single
text only for installed apexes.
This change is a preparation before the upcoming change. We'll reuse the
apexKeyEntry stuff from the current implementation.
Bug: 304914238
Test: m blueprint_tests
Change-Id: If9d5d992e5e2b0120e017265d2590b1c55152f52
Product modules install required vndk modules in /product/lib[64].
But still the product modules can link to the llndk from system
partition using the list in /system/etc/llndk.libraries.txt.
To install /system/etc/llndk.libraries.txt file, use
llndk_libraries_txt singleton without versioned name.
Until VNDK is fully removed, the vndk apex must install the versioned
llndk.libraries.<ver>.txt file to the vndk apex.
Use llndk_libraries_txt_for_apex singleton for this purpose.
Test: lunch cf_x86_64_phone-next-userdebug; m
Test: atest GtsVndkDependencyTestCases
Bug: 299867815
Bug: 302255959
Change-Id: I058616081fe31597a9b76b772b69927807436896
This change fixes a Soong test that is dependent on the build
configuration (from-source stub build vs from-text stub build) by
setting the test configuration to build from source stub and add
an additional test case configured with build from text stub so
that the expected behaviors of both from-source and from-text
stub builds can be tested.
Bug: 275570206
Test: m nothing && m nothing --build-from-text-stub
Change-Id: I483be27ad3eebbf6af050e80265859919fc28fd8
This reverts commit e7c71c344d.
The intermediates created by the separated rust compile steps are very
large, on the order of 60GB. This is more than CI can support for now,
revert the split into compile and link phases. This comes at the expense
of incremental build time, especially when modifying C/C++ sources that
are dependencies of rust modules.
Bug: 293349612
Test: builds
Change-Id: I81169e7d0727330c8de5e7688dcdc87fe7b8d3b5
PRODUCT_PRODUCT_VNDK_VERSION is set to 'current' by default. Now, we
can generate product variants without checking the
PRODUCT_PRODUCT_VNDK_VERSION build variable. Remove reading the
PRODUCT_PRODUCT_VNDK_VERSION variable from soong and generate product
variants by default.
Bug: 302255959
Test: m
Change-Id: I9a9b2076f4367c5ce9a393bbb206f8dee3884bd8
With aosp/2681229, assemble_vintf modifies the input, instead of
checking. APEX should use the output of assemble_vintf instead of
running it as validation.
Bug: 299034304
Test: m
Change-Id: I9446908e1df85b4f3f89d29ebe9cace3982d7757
This no-op refactoring facilitates some upcoming functional changes for
"bp2build allowlist v2". The work requires that the bp2build conversion
mutator be changed from a TopDown mutator to a BottomUp mutator.
Refactoring all bp2build-related methods so that they use Bp2buildMutatorContext
makes it easier to make this functional change without touching tens of
files and multiple projects.
Bug: 285631638
Test: m bp2build
Change-Id: I3d1ef3064146e959c6f0dc315350fc9764bf2bd2
Instead, we return an error. This allows us to access some product
variable information earlier when it will not be used as an attribute
without panicing
Test: m nothing
Change-Id: Id094b2b9e1364a8d174d99b3824fa149fb235b3e
This commit adds support for compiling rust rules inside the sbox
sandbox. To compile a rust module with sandboxing enabled, the entry
point to the crate must be specified via the `crate_root` property, and
all input sources and compile-time data must be specified via the `srcs`
and `compile_data` properties.
Bug: 286077158
Change-Id: I8c9dc5cf7578037a583b4be2e2f73cf20ffd4408
In Make, vintf fragments are checked with assemble_vintf. Since vendor
APEXes can have vintf fragments, perform the same check with vintf
fragments in APEX.
Bug: 299034304
Test: m test.bad2.com.android.hardware.wifi
(should fail if its module type is `apex`)
Change-Id: I2f9ed50066b9b499b3562bfa51214c1e375d5747
`conv_linker_config validate` command is used to validate the linker
configuration embedded in APEX to detect common mistakes.
For example, when used in APEX, linker configuration can't set
provideLibs/requireLibs. For APEX, there are
provideSharedLibs/requireSharedLibs in APEX manifest for that purpose.
One might make mistake by setting provideLibs in linker config.
Now, when these unsupported properties are set, there'll be build-time
error like:
// set provideLibs key in com.android.art's linker config.
$ m com.android.art
...image.apex/etc/linker.config.pb: provideLibs is set. Use provideSharedLibs in apex_manifest
Bug: 264341796
Test: m com.android.art (see above)
Change-Id: Ibaf7322616ad333569e6d721680f3d72243402a2
As VNDK is in deprecation, any Vendor APEX which used use_vndk_as_stable
should copy former-VNDK libraries into its own APEX. However, libbinder
is not allowed to create APEX variant, so it should use libbinder_ndk
instead. This change is to temporalily allow Vendor APEX modules link
with libbinder in /vendor/lib, while any Vendor APEX modules using
libbinder transit into libbinder_ndk.
Bug: 296491928
Test: Cheetah build and boot succeeded
Change-Id: I40beb255bab658b75685e78f48e14520058616d6
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
Since we no longer support "zip" APEX, we don't need "host" support.
For example, we don't need go/python binary support.
Bug: 279835185
Test: m
Change-Id: I6e8d2b205e42662f31866dc9ac7507524effd144
We want to make FULL_SYSTEMIMAGE_DEPS more accurate so that we can
remove the need for `m installclean`.
Currently, the compat symlinks are installed by adding them as
dependencies of other installed files. Doing this doesn't end up
propagaing the compat symlinks all the way to FULL_SYSTEMIMAGE_DEPS.
Add them to LOCAL_SOONG_INSTALL_SYMLINKS, which will cause them to
be propagated to FULL_SYSTEMIMAGE_DEPS.
Bug: 205632228
Test: Full build with a change to delete files not in FULL_SYSTEMIMAGE_DEPS from the staging dir
Change-Id: Idc7fc0a0dbf7c8ac3f0628c16413cd1df69a7821
Revert submission 2718295-colefaust_track_apex_compat_symlinks
Reason for revert: To validate if this change is causing the build breakage.
Reverted changes: /q/submissionid:2718295-colefaust_track_apex_compat_symlinks
Change-Id: I1896530219cf984efdf9ca7f4b14d8784367f242
We want to make FULL_SYSTEMIMAGE_DEPS more accurate so that we can
remove the need for `m installclean`.
Currently, the compat symlinks are installed by adding them as
dependencies of other installed files. Doing this doesn't end up
propagaing the compat symlinks all the way to FULL_SYSTEMIMAGE_DEPS.
Add them to LOCAL_SOONG_INSTALL_SYMLINKS, which will cause them to
be propagated to FULL_SYSTEMIMAGE_DEPS.
Bug: 205632228
Test: Full build with a change to delete files not in FULL_SYSTEMIMAGE_DEPS from the staging dir
Change-Id: I0600ccf8d863d5e29e044c82293ece730fc98d43
Source tree may include prebuilt vndk snapshot libs that are newer
than or equal to the PLATFORM_VNDK_VERSION.
Ignore those prebuilt vndk snapshot libs.
Bug: 296488609
Test: lunch cf_x86_64_phone-next-userdebug; m nothing
Change-Id: I3adaf3b7636f53884f08540959d2ec2fddfb6921
llndk.libraries.txt file is currently located within the VNDK APEX.
However, this file is still required even if VNDK APEX is deprecated.
This change removes llndk.libraries.txt from VNDK APEX, so it can be
installed within the system image.
Bug: 290160925
Test: aosp_cf build succeeded with llndk.libraries.txt in the system
image
Change-Id: I09a0a43babaa58ff16fc04ea71ab41ab68b54b70
For device build, rust defaults to dylib linkage for rustlibs deps. `dylibs` prop was provided for flexibility.
By removing it, we're enforcing users to either use the default linkage (dylibs for device and rlibs for host) or rlibs prop explicitly. This means no dylibs for host modules. This makes sense because host modules always uses rlib linkage against libstd. The flexibility with dylibs prop opened room for linkage collisions because the dependencies don't link against libstd the same way.
Test: go test
Change-Id: I2fc221daa8a9bb42bdcf6d9823c723a4ddabe7b5
Currently vendor APEX can link to VNDK when 'use_vndk_as_stable'
property is set as true. However, when VNDK is deprecated, all former
VNDK libraries should be included in the vendor APEX despite of property
value. This change ignores use_vndk_as_stable when VNDK is set as
deprecated.
Bug: 290318998
Test: aosp_cf_x86_64_phone with WITH_VNDK=false build checked that
Vendor APEX contains all required VNDK libraries within the APEX
Change-Id: I648277d734274e7852b3effc24e7780e55089f75
Adds dylib support for vendor and recovery images.
This changes the default linkage for vendor and recovery images to
dylib, which matches the platform default linkage. This also means that
by default, dylib-std variants are used for rlib dependencies.
Bug: 204303985
Test: Soong tests.
Test: m dist vendor-snapshot
Test: RECOVERY_SNAPSHOT_VERSION=current m dist recovery-snapshot
Change-Id: If84074b8615a70c45e7e162abeb853dc8c34d49a
In the past, dexpreopt for boot jars was very inflexible, and it was
incredibly hard to make a change that is as simple as adding a jar to a
boot image. Boot image generation was handled by
"platform_bootclasspath" and "bootclasspath_fragment" separately. This
caused not only code duplication but also the inflexiblity as such a
design did not fit today's use cases, where a boot image may take jars
from multiple mainline modules and the platform, and a mainline module
can contribute to multiple boot images. The design casued a huge
maintenance burden as any change to the boot image cost multi-week
efforts.
In recent years, efforts have been made to improve this a bit by a bit.
This change is another step towards making dexpreopt reasonable.
After this change, all boot images are generated by "dex_bootjars",
which is in build/soong and is therefore available on both the full
source tree and the thin manifest (master-art). The change decouples
profile generation/extraction from boot image generation. Profiles for
mainline modules are still handled by "bootclasspath_fragment"
because they need to be packed into APEXes when building mainline
modules and extracted from APEXes whem building the system image from
prebuilt modules. Boot images are not handled by
"bootclasspath_fragment" anymore.
Bug: 290583827
Test: m (all existing tests are still passing)
Test: Manually checked that the boot images are exactly the same as
before.
Change-Id: Ib5a5f401bee334ffcab5c26618e0c8888b84575a
This is to decouple profile generation from image configs. A boot image
profile is either for a mainline module or for the platform, which is
orthogonal to boot images.
Bug: 290583827
Test: m nothing
Change-Id: I0918f2fa945a2af1839f1a08ecede331c64d0317
The Modules() method was for the ART boot image in the ART APEX. It's no
longer needed because we don't install the ART boot image in the ART
APEX anymore.
Bug: 290583827
Test: m nothing
Change-Id: I674a5fa1ed18908413a64129df5947c7d26e638e
This CL is to prepare for the changes in http://r.android.com/2652081.
See the description of that CL for the reasons.
Some tests were set up in a fragile way and were easy to be broken when
the implementation changes. This CL is a pure test change that fixes
them.
This CL also removes TestNoUpdatableJarsInBootImage. That test checks
what should go to the ART boot image and what should go to the
platform one, which does not apply today because boot images are not
associated with mainline modules anymore: a boot image may take jars
from multiple mainline modules and the platform, and a mainline module
can contribute to multiple boot images. In practice, we have ART jars in
the platform boot image, and we are going to add core-icu4j and
consrypt to the ART boot image, which is now for testing only.
Bug: 290583827
Test: m nothing
Change-Id: I22c45cbf6f853b030b68edb51197854e9c53a02e
We will deprecate flattened apexes. In this change, GSI-specific make
variable (PRODUCT_INSTALL_EXTRA_FLATTENED_APEXES) is removed. The
variable was used to install both image/flattened apexes in the GSI, so
that it works on ro.apex.updatable devices and not-updatable devices.
Now, GSI will have only image APEXes in it.
Bug: 278826656
Test: lunch gsi_arm64-userdebug && m # no flattened apexes
Change-Id: Ie5fe505b9f2a6a1687252513788fd3e16bc147c5
deapexer doesn't need it.
Bug: 279858383
Test: presubmit
Test: m MODULE_BUILD_FROM_SOURCE=false droid
Change-Id: Ie8311c74682f366cf6aeebb669500d01675cd0bf
Bug: 285138555
Test: b build //build/bazel/examples/... --config=android
Test: b test //build/bazel/tests/... --config=android
Change-Id: I7350930d48ccd13e96bdb4f994f47071a0dde70f
Bug: 285138555
Test: b build //build/bazel/examples/... --config=android
Test: b test //build/bazel/tests/... --config=android
Change-Id: I11372cbc01b89d530a35f90375ca6fa87834edd2
This property allows modifying the variant version that is put into the
APEX manifest.
Bug: 285138555
Change-Id: I42b8c0ddad8822a0a329e99ec4ec62f8c3546ee9
This property allows developers to create multiple modules that provide
the same APEX implemenation with some differences. For example, an APEX
that targets the current SDK can be developed alongside an APEX that
targets a pre-S SDK. Common dependencies of these APEX modules can both
use the value of the apex_available_name property in their
apex_available lists and be packaged in either APEX module.
Bug: 285138555
Change-Id: Ia2cb027e2f19bd6d3d1c02e3d3742a0122a43c97
Since vendor APEXes are installed in vendor partition, there shouldn't
be system_file according to Treble. Instead, we can force-label / and
/apex_manifest.pb as vendor_apex_metadata_file so that apexd (and other
system components) can still read them.
Bug: 285075529
Test: m nothing (soong test)
Change-Id: Idb36b8c4c68b29e2235dbda38ee323d4b781e1d5
AndroidMk assumes that the app is the last file installed, and it uses
this assumption to populate the LOCAL_SOONG_INSTALLED_MODULE entry. This
CL moves the privapp_allowlist installation to before the app
installation to respect this assumption.
Bug: 242509786
Test: go test
Test: OUT_DIR=out.ref m nothing &&
cp aosp/2562351 && OUT_DIR=out.change m nothing &&
GOWORK=$PWD/build/bazel/mkcompare/go.work \
go run android/bazel/mkcompare/cmd -json \
<(sed -e "s/out\.ref/out/g" out.ref/soong/Android-aosp_cheetah.mk) \
<(sed -e "s/out\.change/out/g" out.change/soong/Android-aosp_cheetah.mk)
&& verify manually that the only diffs are related to the removal of
the prebuilt_etc module.
Change-Id: I95ec27070f575e79fb976de68493a219717ed89a
For a non-override android_app, we can assume that the privapp_allowlist
already contains the correct package_name, and so we don't need to
overwrite it in this case.
Bug: 242509786
Test: go test
Merged-In: I0f137e34cae3478dc8b9178d138121ff1d936f07
Change-Id: I0f137e34cae3478dc8b9178d138121ff1d936f07
Verify logic for transitive shared vs static deps to
ensure in Bazel that these are handled similarly.
Test: go test soong tests
Change-Id: I015935fa4d7eb1ac40666d47a8de8e48150a043e
* changes:
Dexpreopt ART jars and framework jars together.
Unify installDirOnHost and installDirOnDevice.
Remove the ability to install boot images by bootclasspath_fragments.
Prepare tests for dexpreopt changes.
