Reverse the order of transitive R.jar classpath entries so that
the R.jar from the current module comes first, and so that R.jar
from any direct dependency comes before the R.jar of any transitive
dependencies through the direct dependency. Also swap the order of
shared and static dependencies so that static dependencies come first
in the final classpath.
Bug: 294256649
Test: m javac-check
Test: TestAndroidResourceProcessor
Change-Id: Id9ea5b53ca563f79d0a25fb52b24552dbea70605
This CL uses OverrideName to ensure that the LOCAL_MODULE does not
contain any version information.
Test: Created CaptiveLoginPortalGoogle.v2, and checked that its
LOCAL_MODULE is CaptiveLoginPortalGoogle
Change-Id: I177441bcd55ca538759b69aafb73d0a8b7261179
The apex_contributions in next builds use prebuilt apexes with source
java_sdk_library for javac. The dexpreopt rules of the source
java_sdk_library are disabled via
RELEASE_DEFAULT_MODULE_BUILD_FROM_SOURCE coupled with some complicated
special-casing in android/prebuilt.go
This special-casing breaks if we want to use prebuilts of some modules,
and sources of other modules. To enable per mainline module
toggelability, explicitly disable dexpreopt of source variant of
java_sdk_library if we use prebuilt of the containing apex.
Test: In internal, updated trunk_staging.scl's
RELEASE_APEX_CONTRIBUTIONS_ADSERVICES to use prebuilt followed by m
nothing
Change-Id: I32daefbd38338b396d6f07b899826b2869d8f8e1
For multiple mainline prebuilts, we will have multiple versioned
prebuilt apps in the tree. The soong name of these prebuilts will have a
version prefix to prevent name collisions (e.g. MyGoogleApp.v2).
This CL introduces a source_module_name property in android_app_imoprt.
This property will be used for the following
1. Determining installation path. This should be
/system/app/MyGoogleApp/MyGoogleApp.apk
and not
/system/app/MyGoogleApp.v2/MyGoogleApp.apk
(filename prop determines the filename and not the dir name)
2. Preventing duplicate installation rules: This property will be used
to create a dependency to the source app, and call HideFromMake on
all the unflagged apps
Test: presubmits
Test: locally # Created CaptivePortalLoginGoogle.v2 and selected it
using one of the RELEASE_APEX_CONTRIBUTION_* flags
Bug: 326995930
Change-Id: If4ab9f9bd295117c96eb062cf3b3d2efc8bfed12
Use the R.txt files from aar imports directly instead of recreating
one using aapt2 from the embedded resources. Fixes an issue with
com.google.android.material where the jar was referencing
com.google.android.material.R.attr.theme, aapt2 was not producing
"int attr theme 0x0" in R.txt, but the aar's R.txt had it.
Bug: 294256649
Test: builds
Change-Id: Ibe1e5535a75eed59f3b8dbbc12eff9c07af51d37
extraCombinedJars contains the R.jar generated by
ResourceProcessorBusyBox for apps. It needs to go before any
static_libs dependencies so that the finalized R values take
precedence over any non-final R values that may have been included
in the dependencies. Moving after the javac and kotlinc compiled
jars helps minimize differences when turning on use_resource_processor
by default by using the MANIFEST.MF generated by soong_zip instead of
the one generated by ResourceProcessorBusyBox, which contains a
different Created-By field.
Bug: 294256649
Test: m javac-check
Change-Id: I8d060594404121fd36ef650ac317f0c5d5f92b23
Setting use_resource_processor: true can increase the length of the
classpath enough to trigger "command line too long" errors. There are
clockwork libraries with 546 transitive android_library dependencies.
Write classpaths longer than 64kB to a separate file and add them
to the javac and turbine command lines with the @file syntax.
Bug: 294256649
Test: m checkbuild
Change-Id: I2b6a57ae30de03347db3221e9c9a4b2efb490115
This change adds support to generate non-"everything" (i.e. "runtime"
and "exportable") stubs in java_api_library, which generates the stubs
from the api signature files.
Unlike droidstubs module that generates "everything", "exportable" and
"runtime" stubs in a single module, java_api_library generates a single
set of stubs per module, which is set by the default-"everything"
property `stubs_type`. This is because java_api_library is responsible
for both generation and the compilation of the stubs srcjar, and
compilation of the stubs srcjar are done in separate java_library
modules for from-source stubs.
Utilization of this feature will be done in a follow up change that
generates the "exportable" java_api_library modules in java_sdk_library.
Test: m nothing --no-skip-soong-tests
Bug: 318009570
Change-Id: I1051544ac3bcdb3ba1f78bfec28eba4e9fad9c2d
Similar to how the exportable stubs are generated in droidstubs, this
change adds the rule to generate the runtime stubs in droidstubs. Unlike
the exportable stubs, which the artifacts are dist'ed during the sdk
build, the runtime stubs will only used in the hiddenapi flags
generation. Therefore, only the stubs are generated and no other
artifacts are generated during the "runtime" metalava invocation. When
`aconfig_declarations` property is not defined (i.e. no flags are
enabled, thus the exportable and the runtime stubs are identical), the
runtime stubs are simple copied from the exportable stubs.
Note that the runtime stubs are not a dependency of `droid` as of now.
The dependency of the hiddenapi flags will be replaced to the runtime
stubs in the child CL.
Test: m nothing --no-skip-soong-tests && m api-stubs-docs-non-updatable
Bug: 319162970
Change-Id: I14928b7b5619522c4caab1dfc795bc9c7e929639
This change performs additional cleanups in the build rules of the
droidstubs module, specifically optionalizing annotationFlags(...) and
apiLevelsAnnotationsFlags(...). This is required as "runtime" stubs
would not generate other artifacts than the stubs, and thus
`stubsArtifacts` would not be generated for "runtime".
Test: m nothing
Bug: 319162970
Change-Id: Ia009df3d01f49841d5041fb2dfdfa7ef8671bf18
Support the feature with new property combined with architecture and dpi
resolution.
Bug: 319381869
Test: go test -run TestAndroidAppImport_ArchVariants
Change-Id: Ib43cbae8868fc35701e6666867b2325f5abbb2c7
RELEASE_EXPORT_RUNTIME_APIS build flag is currently used to modify the
filter condition for the "exportable" stubs, so that it exposes wider
set of flagged apis (ENABLED && READ_ONLY vs ENABLED || READ_WRITE).
This flag was originally introduced as a build flag to be enabled in
specific release configurations, but instead this is used as a product
variable that will be enabled in the product `sdk_with_runtime_apis`,
which will be introduced in a future change.
Test: m nothing --no-skip-soong-tests
Bug: 326312949
Change-Id: Ieb3cee517dd6cedcca844a9eab270aedf8199d4e
Currently, the "exportable" stubs are copied to the dist directory by
default when building the java_sdk_library module. However, "everything"
api files (current & removed) are copied to the dist directory, causing
confusion to the developers. This change modifies the default behavior
so that the "exportable" api files are copied to the dist directory and
match the behavior of the stubs.
Test: m nothing
Bug: 325639165
Change-Id: I2e3b158bb638d30629120b32aa3e88bb26231020
This allowlist contains java_library modules which set the no-op
property `platform_apis`. This allowlist will help enforce that there
are no new violations.
This should be a no-op till
https://android-review.git.corp.google.com/c/platform/build/soong/+/2969451
is submitted
Test: presubmits
Bug: 215379393
Change-Id: I49372e1d476201f607cd717be26aa3909668ff26
jarjar_prefix propagation logic currently depends on the type of the
providers of the dependencies, thus the logic needs to be updated when a
new provider is added. Since `aconfig_declarations_group` module type
utilizes its custom provider "CodegenInfoProvider", this change adds
jarjar_prefix propagation support for this provider.
Test: Set aconfig_declaration module's exportable property to true && m framework-minus-apex and inspect if "repackaged-jarjar" subdir exists in outdir
Bug: 310504781
Change-Id: I1689027d7810687a53ec34b9cfda479806f2ec87
At ToT, an optional_uses_libs is not added to the build time CLC if it
does not exist in the tree. One edge case here is
java_sdk_library_import, which might exist in the tree, but without an
implementation. This cause issues during analysis when we try to verify
the correctness of the build time CLC.
This CL disables dexpreopt if a dependency does not have an
implementation. To limit inadvertent side effects, this is restricted to
java_sdk_library(_import) module types. (more precisely, it is restricted
to java_sdk_library_import, since the source module type will always
have an impl)
Bug: 315802285
Test: Added a unit test
Test: m nothing
Test: printf debugging in internal main, verified that this CL does not
disable dexpreopt on any android app inadvertently
Change-Id: I173fc2f3ff654fe4091e9a43322164afd3222ee7
This change enabled aconfig_declarations_group module type to be added
as `aconfig_declarations` property of droidstubs module. Similar to
aconfig_declrations module, the aconfig_declarations_group module
provides the intermediate cache files of the aconfig_declarations
modules of the listed codegen modules to droidstubs module.
Test: m nothing --no-skip-soong-tests
Change-Id: I42eb64d3ab65e679ea733c5bb98833971e49a8e8
Overridden packages can have different package names. This change reads
output APKs to parse package name, instead of manifest xml.
Bug: 325011777
Test: boot and idmap2 dump
Change-Id: I748b9db8bd6282d7f3a1478cf94b21580c7683e7
Add more explicit checks to not propagate JarJarProvider when we will be
linking against stubs.
Bug: b/310504781
Test: treehugger
Merged-In: I3219d0bf7e84a386b16b248314f11b4e9edcd0fa
Change-Id: I3219d0bf7e84a386b16b248314f11b4e9edcd0fa
is_stubs_module property signifies whether the module compiles stubs or
not. The information is propagated to the reverse dependencies of the
java_library/java_sdk_library modules via JavaInfoProvider as
StubsLinkType, a ternary state that provides information about whether
the provided jars are compilation of stubs or implementation, or
unknown.
When java_sdk_library sets StubsLinkType, its state is Unknown as the
decision of providing stubs vs implementation jar differs by the reverse
dependency.
Note that this CL does NOT propagate the property up to its reverse
dependencies. This will be done in follow up CLs.
Test: m nothing
Bug: 310504781
Merged-In: Ic81488dbd1c9af1b5d31a33e5e9441d9f1416dbe
Change-Id: Ic81488dbd1c9af1b5d31a33e5e9441d9f1416dbe
--no-static-lib-packages was removed when compiling libraries with
use_resource_processor: true enabled, but that caused problems resolving
attributes of styleables. androidx.preference declares the "icon"
attribute inside a <declare-styleable>, but doesn't give it a format.
aapt2 refuses to create a new attribute for this case (b/131100106),
but without --no-static-lib-packages aapt2 can resolve the attribute
from the one defined in androidx.appcompat.
Bug: 294256649
Test: builds
Change-Id: I13661be83ba6501b0c2b1af8e632f260f405a370
Because
1) it has no effect.
2) it will simplify build commands, which will minimize differences
among targets using generate_product_characteristics_rro
Bug: 322932641
Test: TH
Change-Id: I16afae597038da7489989483f8c926916d207df5
The runtime in S and above does not have the same constraints that
require the hiddenapi flags to be generated in a monolithic manner.
This CL restricts the verify_overlaps to pre S modules. This will
filter out hiddenapi signature discrepancies that do not require
any action.
Test: verify_overlaps diff with this change https://diff.googleplex.com/#key=xxB0ky93hZRn
Test: presubmits
Bug: 313672880
Change-Id: Ie626a6779fc924563bec90b6c1ab0c7e8b4b23c2
UNBUNDLED_BUILD_TARGET_SDK_WITH_DESSERT_SHA enables user to specify
${codename}.${sha} as min_sdk_version and target_sdk_version in order to
support mainline train building into android build.
Test: TH
Bug: 295905124
Change-Id: I032d464aaa7314520f98b8eafa53d962940075ce
Extend default use of uncompressed dex for non-privileged system apps
that are preopted. This avoids unnecessary disk usage on the
/system_other/ partition, as well as the marginal overhead of
extraction after mainline updates.
In total, this saves ~5-15MB cumulatively across partitions.
Bug: 318730708
Test: m + compare image sizes
Change-Id: Id0a06965e61763f59c53cbe2b327cdcf1e5d422b
Bug: 323931246
Test: m nothing --no-skip-soong-tests
Test: Manual test using a locally created build rule
Merged-in: Icd15d63c29560dc219dba07cc9db2a5e1b883532
Change-Id: Icd15d63c29560dc219dba07cc9db2a5e1b883532
EngProd has indicated that we need to be included in that suite to
support TEST_MAPPING files in their infrastructure.
Bug: 308854804
Test: TH
Merged-in: I763b033f0f5f275091db45ab62df6af48dcddc66
Change-Id: I763b033f0f5f275091db45ab62df6af48dcddc66
Currently in SDK build, "exportable" stubs are used to generate the
android.jar and the corresponding build artifacts, as well as the
hiddenapi flags. "exportable" stubs only include the flagged apis that
are "enabled" and "read only", and exclude all other flagged apis. This
will be replaced with "runtime" stubs in the long run, which include
"read_write" flagged apis on top of the "enabled" and "read only" flags.
Prior to Trunk Stable, the SDK build did not distinguish the target
audience of the SDK. That is, the identical build target was used to
generate the SDK targeted toward the Google3 developers (i.e. Google3
SDK drop) and the SDK targeted toward the public (i.e. Developer
Preview). However, given that we now have "experimental" apis with Trunk
Stable, there are demands to differentiate the SDK based on the target
audience, so that the "experimental" APIs are included in the SDK
targeted toward Google3 while they are excluded in the public facing
SDK.
The long term solution to achieve this is to generate the hiddenapi
flags and (conditionally) the SDKs using the runtime stubs. However, as
this is high priority, this change resolves the problem by modifying the
filter condition of the "exportable" stubs to include the "read_write"
flagged apis on top of the "enabled" and "read only" flagged apis when
the value of the default-false build flag "RELEASE_EXPORT_RUNTIME_APIS"
is set to true.
Note that this is a temporary solution; However, we might need to keep
the "RELEASE_EXPORT_RUNTIME_APIS" build flag even in the long run to
determine what set of apis are included in the generated SDK, based on
the target audience of the SDK.
Test: m nothing --no-skip-soong-tests
Bug: 323188988
Change-Id: If0d5fa74b3ba6f4a57c86aade8d340f149a657a2
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
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
android/prebuilt.go#isSelected has a special-case inside it to ignore
apex_contributions contents for the top-level java_sdk_library hook.
This was necessary because even though we might want source stubs in
next builds, we still needed the top-level prebuilt hook to be active to
emit the dexpreopt rules to .mk.
This worked fine for rdeps that create a dependency edge on the child
stub modules of java_sdk_library. Notable examples include the full
android api stubs created by f/b/api.go. In postdeps mutator, these
expanded deps get rewritten to source/prebuilt if necesssry.
The exception to this are workflows which depend on the top-level hook
directly via `libs`. We resolve these rdeps to an appropriate provider
during GenerateAndroidBuildActions stage. This meant that rdeps were
getting prebuilt stubs of these even in next builds.
Bug: 323454855
Test: Added a unit test
Test: lunch cf_x86_64_only_phone-next-userdebug
Test: aninja -t query
out/soong/.intermediates/packages/modules/Permission/SafetyCenter/Config/safety-center-config/android_common/javac/safety-center-config.jar
| grep prebilts/module_sdk # empty now
Change-Id: Id91333d88055519f3c58ab40466f9628085f5180
LOCAL_DROIDDOC_STUBS_SRCJAR is used to copy entries to OUT_DOCS in
build/make/core/soong_droiddoc_prebuilt.mk, which defines the copy rules
to generate the docs. When generating the documentation, the exportable
stubs should be set as dependencies, so that disabled flagged apis are
not exposed. Thus, this change modifies the entries passed to
LOCAL_DROIDDOC_STUBS_SRCJAR from the everything stubs to the exportable
stubs.
Likewise, all other LOCAL_DROIDDOC_* entries are copied to dist during
sdk builds. Therefore, this change replaces the everything artifacts to
the exportable artifacts.
This change also config-guards the exportable stubs generation, so that
the exportable stubs are not generated when the droidstubs module does
not generate the stubs.
Test: m docs dist && inspect ninja file to verify that everything stubs are not exported
Bug: 323261972
Change-Id: Ic04fb47ad311aefafc2f1a7b8bb15525050ecd2e
How it works:
1. build/make/core/Makefile generates a txt file with the kernel
version, which is taken from an explicit BOARD_KERNEL_VERSION value,
or extracted from the kernel image on the source tree, or extracted
from the kernel image extracted from the prebuilt boot.img.
The file is saved at
$ANDROID_PRODUCT_OUT/obj/PACKAGING/check_vintf_all_intermediates/kernel_version.txt.
2. If PRODUCT_ENABLE_UFFD_GC is "default", meaning the GC type needs to
be determined by the kernel version, build/make/core/Makefile copies
kernel_version.txt to
out/soong/dexpreopt/kernel_version_for_uffd_gc.txt.
3. build/soong/dexpreopt/config.go writes the the UFFD GC flag to
out/soong/dexpreopt/uffd_gc_flag.txt. The flag is determined by an
explicit PRODUCT_ENABLE_UFFD_GC value or by contruct_uffd_gc_flag.py,
which reads kernel_version_for_uffd_gc.txt and determines the flag
accordingly.
4. dex2oat takes the UFFD GC flag from uffd_gc_flag.txt.
5. post_process_props.py mangles ro.dalvik.vm.enable_uffd_gc based on
the same logic.
Bug: 321751629
Bug: 319554951
Bug: 318763448
Bug: 319648491
Test: m --no-skip-soong-tests nothing
Test: atest uffd_gc_utils_test
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with no
UFFD support -
1. Check the existence of `-Xgc:CMC` in
out/soong/dexpreopt_arm64/dex_bootjars/android/system/framework/arm64/boot.invocation
(dex2oat invocation for a boot image)
2. Check the existence of `-Xgc:CMC` in
out/soong/.intermediates/packages/apps/Settings/Settings/android_common/dexpreopt/Settings/oat/arm64/package.invocation
(dex2oat invocation for an app defined in .bp)
3. Check the existence of `-Xgc:CMC` in
$ANDROID_PRODUCT_OUT/obj/APPS/Dialer_intermediates/oat/arm64/package.invocation
(dex2oat invocation for an app defined in .mk)
4. Check the value of ro.dalvik.vm.enable_uffd_gc in
$ANDROID_PRODUCT_OUT/product/etc/build.prop
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with
UFFD support, and do the steps above.
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=true m`, and do the steps
above.
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=false m`, and do the steps
above.
Change-Id: I035ad32233e49e2a30ce11f6c7c318a648511ef8
Api levels annotations flags should respect the stubs type, but the
everything api versions xml file was being passed to the metalava
invocation for both everything and exportable metalava invocation.
This change fixes such issue by setting api versions xml file (passed to
metalava as --apply-api-levels argument) to respect the stubs type.
Test: m nothing --no-skip-soong-tests
Bug: 319162970
Change-Id: If7155b3701b32fb4cd81dc918648b449de090201
For prebuilts, the dexpreopt rules of system server jars are now
generated from the context of the top-level prebuilt apex and not in the
context of the shim java_import modules. Since
`dex_preopt.profile_guided` property is defined in java_import, this
needs to be bubbled up to the top-level apex. This will be done using
deapxerInfo. If profile_guided of a transitive java_import is true, the deapexed .prof file will be
set as dexreopter.inputProfilePathOnHost before invoking
dexpreopter.dexpreopt. This ensures that only that java_import undergoes
profile guided dexpreopt, and not every other transitive java_import
Test: go test ./apex -run TestPrebuiltStandaloneSystemserverclasspathFragmentContents
Test: lunch cf_x86_64_only_phone-next-userdebug && m
$ANDROID_PRODUCT_OUT/system/framework/oat/x86_64/apex@com.android.art@javalib@service-art.jar@classes.odex
Test: du -sh
$ANDROID_PRODUCT_OUT/system/framework/oat/x86_64/apex@com.android.art@javalib@service-art.jar@classes.odex
24K
Bug: 308790457
Change-Id: Ibf46ecb400b3f126b243fc8d27b08d9a1aa4cc97
Even when building stubs from source, the rules for the
java_api_library modules are generated although they are not
executed. This leads to NPE, as setting `WITHOUT_CHECK_API=true`
prevents `checkCurrentApiTimestamp`, which the java_api_library modules
depend on, from being generated.
To prevent the NPE, this change prevents the `checkCurrentApiTimestamp`
from being registered as the dependency of the java_api_library modules
when `WITHOUT_CHECK_API=true` is set.
Test: BUILD_FROM_SOURCE_STUB=true WITHOUT_CHECK_API=true m nothing
Bug: 320601440
Change-Id: I4f19e30d9cd74bdc20dde0d14884fb03ff223ccb
This CL is the java_(test_)_import equivalent of aosp/2928483.
With trunk stable, we will have
multiple prebuilts of the prebuilt java .jars in
prebuilts/module_sdk/art/<v>/test-exports/, and this CL introduces a
mechanism to use apex_contributions to select a specific versioned
prebuilt when building.
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. This property also
becomes the stem, if `stem` is not set explicitly.
Bug: 322175508
Test: Added a unit test
Change-Id: I2dff38acdf2002355586dbb2be8c1f98af4741f7
strict_updatability_linting currently only checks that updatability
checks aren't disabled via disabled_checks / warning_checks, you could
get around it using the `flags` property. Only allow controlling checks
via the *_checks properties.
Bug: 322802379
Test: m nothing --no-skip-soong-tests
Change-Id: Ia311622e1409f9cc201ab55f8749f2d13fccf551
For prebuilts, java.dexpreopt gets called twice
1. in the context of the top-level prebuilt apex
2. in the context of the java_library shim
Only the artifacts of (1) get installed. The artifacts generated by 2)
are unused. However the args used to generate the artifacts of (1) are
incorrect. It uses moduleName(ctx) to do special-handling of apex system
server jars. This special-handling does not happen in (1), so although
dexpreopt artficats get generated, they get generated with the wrong
args.
To fix this, add an additional parameter in java.dexpreopt to pass the
libraryName explicitly.
Details
- Delete moduleName function. This was used to determine the java
library name, which is no longer safe
- Add a libraryName parameter to java.dexpreopt
- Most module types will use j.Name() as libraryName
- prebuilt_apex and apex_set will iterate over its `contents` and use
each element as libraryName when invoking java.dexpreopt
With the correct args passed from (1), we can drop j.dexpreopt from (2)
completely. Dropping (2) also breaks profile guided dexpreopt tests.
These currently operate on (2). They will be moved to (1) in the next CL
of this stack.
Test: presubmits
Test: lunch cf_x86_64_auto-trunk_staging-userdebug && m nothing (this
was a postsubmit failure with aosp/2923733)
Test: art_standalone_dexpreopt_tests on next https://android-build.corp.google.com/builds/abtd/run/L86000030001579256
Test: art-gtest on git_master-art-host https://android-build.corp.google.com/builds/abtd/run/L07800030001550262
Bug: 308790457
Bug: 322255144
Change-Id: I8eb604c82f1fa5289d3cd1a20084d56e4d7485e3
Setting the RELEASE_USE_RESOURCE_PROCESSOR_BY_DEFAULT build flag will
change the default for use_resource_processor from false to true.
Bug: 294256649
Test: builds
Change-Id: If643bf8db9e2e039200f63f4aac226ed5b44d9e0
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
Given that WITHOUT_CHECK_API=true is incompatible with from-text stub
build, this change makes the module raise an error when the two
conflicting configurations are set.
This change also modifies the checkapi error message, that
DISABLE_STUB_VALIDATION does not bypass checkapi.
Test: m nothing --no-skip-soong-tests && WITHOUT_CHECK_API=true m nothing
Bug: 322060779
Change-Id: I597309baa8fcfbefa05863c7b392bfb8b6774cea
In order to prepare generating "runtime" stubs in droidstubs, this
change performs some cleanups, which are:
- Modify droidstubs providers methods to take a StubsType enum as an
input, in order to remove exportable-specific providers. The methods
are also modifed to return an error when the artifact is not provided
for the input StubsType.
- Wrap droidstubs artifact to a struct. This removes artifacts common to
all stubs types from being written out as a individual module property
(e.g. exportableAnnotationsZip -> exportableArtifacts.annotationsZip)
Test: m nothing --no-skip-soong-tests
Bug: 319162970
Change-Id: I6d6c57c5417ca71eab5ddda7981b71fd84fa6ee1
The different roles of stubs (e.g. dependency to java modules,
hiddenapi, dist to sdk snapshot) are now split to different set of stubs
(everything, exportable and eventually runtime), while a single set of
stubs are responsible for all roles for the prebuilt stubs. Thus, the
stubs from source are depending different stubs tag (e.g.
everythingStubsTag, exportableStubsTag), while the prebuilt stubs
utilize stubsTag. Given that this tag is only used for the prebuilt
stubs, it can be renamed to `stubsTag`.
Test: m nothing --no-skip-soong-tests
Bug: 319162970
Change-Id: Iacdf434fab6a403482fd2f1de24e6f260ad80756
* changes:
Add script to run Soong tests with go tools
Disable TestVariantSingletonModule when go test -short is used
Fix data race in propagateRROEnforcementMutator
Fix data race in finder_test.go
Fix data race in dex_bootjars
Fix race CommonGlobalCflags when running tests in parallel.
Fix data race in snapshot singletons when running parallel tests
propagateRROEnforcementMutator walks dependencies of each module and
modifies them via SetRROEnforcedForDependent. That is unsafe in a
parallel mutator, as the same dependency could be being visited by
two parent modules at the same time. Don't mark it as a parallel
mutator.
Test: go test -race ./...
Change-Id: I9870aaa7d165bf72b751e3ceff5a2a3eb4d74ec4
Move fields in bootImageConfig that are written during
GenerateAndroidBuildActions into a provider to avoid a data race.
Test: go test -race ./...
Change-Id: I0d6783530843889b96f32d748bda7824493d2e32
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
With the recent build changes to support generating mainlin module sdk
with flagged apis, the build no longer depends on the values of these
product variables in exposing the flagged apis, but these are determined
by the aconfig flags. Given that these variables are no longer used,
this change removes these variables and the variables dependent code.
Test: m nothing --no-skip-soong-tests
Bug: 320515715
Change-Id: I6af94da73cc7fc7ffce670928aad81cec5d383b4
Currently, android_app_import modules get disabled during their load
hook if they don't have a set `apk` property. This causes them to be
disabled before soong config variables can be applied, which would've
set the apk property.
Move the disabling into a DefaultableHook, which will run after the
soong config variables.
Bug: 319897584
Test: m nothing --no-skip-soong-tests
Change-Id: Ia0f6a39c35b3b11249bfa74ad532858189be24b1
* 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 copy rules of the sdk_library when generating
the module sdk snapshots so that the exportable artifacts (annotations
zip, api file, removed api file, srcjar file) are copied instead of the
everything artifacts.
In order to satisfy the prebuilts compatibility, this feature is flag
guarded by the build flag "RELEASE_HIDDEN_API_EXPORTABLE_STUBS"
Test: m --no-skip-soong-tests
Bug: 315027929
Change-Id: I8bf5bb1f196aa9b5db78ba4677caa5f4337e3021
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
This change transforms the bootclsspath_fragment module into a
defaultable module, in order to modify the "art-bootclasspath-fragment"
module definition based on the build flag in
https://r.android.com/2897389
Test: m nothing
Bug: 315027929
Change-Id: I01ba7b15e4fcdea9bd31c369110a3c9ee38bc9f6
The aconfig command has been recently updated to fully specify the
output format instead of passing the keyword format (e.g., bool). This
change reflects the change in the aconfig tool.
Test: m art.module.public.api && inspect the generate released-flagged-apis-exportable.txt output
Change-Id: I620b7f34c346288ca87342448f50a0e90813304f
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
While the static rule depends on the keep-flagged-apis binary, the
command deps was mistakenly not specified. This change fixes the rule.
Test: m
Change-Id: I4875ac516e0e03389eb6a09d720c94f28710fbc9
Given that now the droidstubs module generates the "exportable" stubs,
this change modifies java_sdk_library to generate the java_library
modules that compiles the "exportable" stubs per api scope.
The detailed naming scheme of the generated modules are available in the
bug linked in the footer.
Similar to the from-text java_api_library vs from-source java_library
static lib selection for the "everything" stubs, the "exportable" stubs
module can also toggle between the stubs java_api_library and the
java_library module. However, given that the "exportable" stubs
generation has not been implemented for from-text stubs, the module
always default to depend on the from-source "exportable" stubs compiling
java_library module.
Test: go test ./java
Bug: 315495926
Change-Id: I5798312c1338c55625b2030da728b056385171a4
This change adds support for the droidstubs module to export the
"exportable" artifacts via OutputFiles(tag string) method, while
supporting the current behavior of exporting "everything" artifacts via
a tag. With the support, a rdep module can depend on the "exportable"
(and "runtime" in the long run) artifacts by prepending the stubs type
in the tag. For instance, given that the currently supported tag
{.annotations.zip} exports the everything annotations.zip file,
{.exportable.annotations.zip} tag will export the exportable
annotations.zip file. For an unsupported combination (e.g. all runtime
stubs related artifacts as of now), an error will be thrown.
Test: m nothing --no-skip-soong-tests
Bug: 315490657
Change-Id: Idcefd9cdc02d323306fb8d7be2a2b34f67501f56
This change generates rules for "exportable" stubs in the droidstubs
module.
Given that there are a lot of overlap between the currently existing
"everything" stubs rule and the newly introducing "exportable" stubs
rule, the currently existing metalava rule commands are modularized to
be utilized in the "exportable" stubs rule commands.
The currently existing build actions are modularized in the followings:
- commonMetalavaStubCmd(...): metalava commands that are required for
generation of both "everything", "exportable", and potentially
"runtime" stubs
- everythingOptionalCmd(...): metalava commands that are dependent on
"everything" stubs and not dependent on flagged apis annotations, such
as api lint, released api check
Based on this modularization, the "everything" stubs are now generated
in everythingStubCmd(...), which calls commonMetalavaStubCmd(...) and
everythingOptionalCmd(...).
Similarly, the "exportable" stubs are generated in
optionalStubCmd(stubsType=Exportable, ...), which calls
commonMetalavaStubCmd(...) and appends additional flags. Runtime stubs
can be generated similarly in the future with
optionalStubCmd(stubsType=Runtime, ...).
"everything"-related artifacts will now be created in
`everything/` subdirectory, and "exportable"-related artifacts will be
created in `exportable/` subdirectory. For example, the outdir of a
droidstubs module "foo" would look like below:
```
foo
|-- everything
| |-- foo_api.txt
| |-- foo-stubs.srcjar
|
|-- exportable
|-- foo_api.txt
|-- foo-stubs.srcjar
```
The module generates the build rules for the "exportable" stubs
regardless of whether the module defines the `aconfig_declarations`
property or not. All APIs marked with `@FlaggedApis` annotations are
stripped out for the "exportable" stubs when the `aconfig_declarations`
property is not defined. On the other hand, only the `@FlaggedApis` that
are specified in the aconfig_declarations module and are enabled will be
included (and all others are stripped) when the `aconfig_declarations`
propety is defined.
Test: go test ./java && BUILD_FROM_SOURCE_STUBS=true m
Bug: 315490657
Change-Id: I300273cd2a62fa978b046c0268e3a67c35e22b08
In consideration of the incremental build performance, this change let
droidstubs and java_sdk_library (which generates droidstubs per api
scope) modules to specify `aconfig_declaration` modules where the
dependent flags are defined in via the "aconfig_declarations" property,
opposed to passing uniform "all_aconfig_declaration"-generated flag
arguments to metalava.
When "aconfig_declarations" property is defined for java_sdk_library
modules, the property is passed to the generated droidstubs modules.
When "aconfig_declarations" property is defined for droidstubs modules,
the all aconfig_declaration modules listed in the property are listed as
deps, all cache protobuf files are gathered and metalava-consumable
flags are generated in "revert-annotations.txt".
Although this change introduces scalable implementation to easily
support generation of the "runtime" stubs corresponding flags, actual
support of the runtime flags/stubs will be done in future changes. This
change mostly focuses on the generation of the "exportable" flags.
Utilization of the generated "exportable" flags will be done in future
changes.
Test: go test ./java
Bug: 315485740
Change-Id: I37becd1b9dd9069d7ac4abed130906df30b3fdf4
Simplify running lint on a module by adding a per-module phony target,
e.g. Gallery2-lint.
Bug: 216462289
Test: m Gallery2-lint
Change-Id: I9d4ab362bb116d49f00fc3f79d61d7239528d575
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
lintable modules currently pick up files named "lint-baseline.xml" to
use as the lint baseline implicitly. This is confusing because you could
end up using the baseline files in more modules than intended. Lint also
has a feature where it requests you remove unnecessary findings from the
baseline file, so something could be necessary for one module, but
unnecessary for another that accidentally picked up the baseline.
All modules that used to pick up the baseline implicitly have been
fixed to specify it explicitly already.
Fixes: 272769514
Test: Presubmits
Change-Id: Id17202e2d119b87ab82c18cb35410b93ed8d5071
This change disallows Java modules in the vendor partition to use System
SDK that is newer than API level 34; 34 is the latest allowed.
Background 1: with Trunk Stable, the system/vendor interface is released
at Q2 whereas the system/app interface is released at Q3. In other
words, at Q2, the APIs which will be added to the system SDK at Q3 are
not available. Since the system/vendor interface (which is fronzen at
Q2) is what the modules in the vendor partition will be building
against, they can't and shouldn't use those new APIs that will be added
in the future (Q3). Using those APIs is risky because there's a chance
that those APIs get removed or changed between Q2 and Q3. For example,
2024 Q2 is technically still Android U, not Android V.
Background 2: The use of Java APIs in the vendor partition had many
issues. Most significantly, those "vendor" Java apps are categorized as
part of the system partition because all Java app processes require
access to platform internal libraries that are prohibited to vendor
processes. Furthermore, since the Project Treble, the vendor partition
was re-purposed to a partition to host SoC-dependent bits - usually
HALs. Implementing HALs in Java has never been officially supported and
has had many loop holes.
We'd like to use both background 1 and 2 as a chance to disallow any
Java code in the vendor partition. However, since there are already some
Java modules in the partition, we can't suddenly ban it. The deprecation
will be made gradually, and this CL is the start.
Note that sdk_version: "current" or "system_current" is automatically
overridden into 34 or system_34. This is to prevent sudden breakage of
vendor modules that have been targetting the latest (i.e. current) API
level. They will however fail if they use APIs newer than API level 34.
Bug: 314011075
Test: m blueprint_tests
Change-Id: I59f5ac15ce9ac2ff7cc89e9c110169359077c37c
When --custom-package is specified as an aapt2 flag translate it to
--packageForR when running ResourceProcessorBusyBox.
Bug: 294256649
Test: m javac-check
Change-Id: I2c97c760ea8a0203790feda82b98e12c2dbd7b72
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
This is needed to be compatible with JDK 21+ which does not allow
other platforms (apart from the ones listed in the modules
plugin) when linking a system image.
Note the value of target platform doesn't matter to us, we just
choose a closest one to replace "android".
Bug: 313924276
Test: m EXPERIMENTAL_USE_OPENJDK21_TOOLCHAIN=true
Change-Id: Id805f31089fdbd78bf4db06c89ae391f25563448
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
Since OtherModuleHasProvider will be deprecated soon, replace it with OtherModuleProvider
Test: go build ./java
Change-Id: I79736e44d85bc6e8c97f08ebf783b40533a3e6ae
Writing raw files as rules in the ninja file unnecessarily bloats
the ninja file. Write files immediately to disk instead to files
based on the hash of the contents, and then emit ninja rules to
copy the files into place during the build. Delete obsolete files
in a singleton at the end of analysis.
Bug: 306029038
Test: Run: m libc_musl_version.h
touch build/soong/Android.bp
m libc_musl_version.h
libc_musl_version.h/genrule.sbox.textproto is not recopied.
Test: Run: lunch aosp_cf_x86_64_phone-userdebug
m libc_musl_version.h
lunch aosp_x86_64-userdebug
m libc_musl_version.h
lunch aosp_cf_x86_64_phone-userdebug
m libc_musl_version.h
libc_musl_version.h/genrule.sbox.textproto is recopied but restat prevents rerunning the genrule.
Test: Run: touch out/soong/raw-aosp_cf_x86_64_phone/00/foo
touch build/soong/Android.bp
m nothing
out/soong/raw-aosp_cf_x86_64_phone/00/foo is removed.
Change-Id: I172869c4d49565504794c051e2e8c1f7cf46486e
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
Previously, the path to built files in the sandbox would be
out/.intermediates/... instead of out/soong/.intermediates/....
After this cl, it will be out/soong/.intermediates/.... This makes
it more consistent with the non-sandboxed paths, which is easier for
developers.
CtsApkVerityTestDebugFiles is a genrule that's used to find the paths
to other modules. Developers were expected to build it, then copy all
the files listed in its output file to a temporary directory. Those
paths would be wrong before this change.
Bug: 307824623
Test: ./build/soong/tests/genrule_sandbox_test.py CtsApkVerityTestDebugFiles
Change-Id: Iadf9e3240a2c828567e46b6b02cc14004f30e8bf
System property was removed in
https://r8-review.git.corp.google.com/c/r8/+/82140, as the
system property com.android.tools.r8.emitRecordAnnotationsInDex
is the only system property for not desugaring records.
Test: Existing
Fixes: b/316501817
Change-Id: I057a18c9e02a99365e910d3128890fd481e93541
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
TestAarImportProducesJniPackages was attempting to assert that an
aar_import module always had a JniPackageProvider, but was instead
asserting that the return type was always a JniPackageInfo. Since
ModuleProvider returned the zero value of JniPackageInfo even when
there was no provider that was always true.
Fix aar_import to always set JniPackageProvider.
Test: TestAarImportProducesJniPackages
Change-Id: Idaf106e14373490d4eb807892e174aaaf094bbcf
art java_test modules need to specify compile_data, make it common
to all java modules.
Bug: 307824623
Test: m lint-check
Change-Id: I68640f14137f9cadaf0c454d3b5abc9e2d1d9b4b
Use of `--hide-annotation android.annotation.FlaggedApi` was always an
intermediate solution until the required semantics for `@FlaggedApi`
was determined. The `--revert-annotation` option provides those
semantics. When the `@FlaggedApi` is applied to an existing API, e.g.
because it has moved from system to public, or because it has changed
in some way, e.g. modifiers, then the correct semantics for when that
API is not required is not to hide the API but to revert it to what it
was before the change necessitating the `@FlaggedApi` annotation was
made.
Use --revert-annotation instead of --hide-annotation
Use of `--hide-annotation android.annotation.FlaggedApi` was always an
intermediate solution until the required semantics for `@FlaggedApi`
was determined. The `--revert-annotation` option provides those
semantics. When the `@FlaggedApi` is applied to an existing API, e.g.
because it has moved from system to public, or because it has changed
in some way, e.g. modifiers, then the correct semantics for when that
API is not required is not to hide the API but to revert it to what it
was before the change necessitating the `@FlaggedApi` annotation was
made.
Use --revert-annotation instead of --hide-annotation
Use of `--hide-annotation android.annotation.FlaggedApi` was always an
intermediate solution until the required semantics for `@FlaggedApi`
was determined. The `--revert-annotation` option provides those
semantics. When the `@FlaggedApi` is applied to an existing API, e.g.
because it has moved from system to public, or because it has changed
in some way, e.g. modifiers, then the correct semantics for when that
API is not required is not to hide the API but to revert it to what it
was before the change necessitating the `@FlaggedApi` annotation was
made.
Bug: 314196587
Test: ./gradlew
Change-Id: Ic97f29dd2b9f598ba0851f5f622c2a2724f18037
Remove the ConvertWithBp2build implementations from all the module
types, along with the related code.
Bug: 315353489
Test: m blueprint_tests
Change-Id: I212672286686a318893bc7348ddd5a5ec51e77a7
Compile_data is a property on rust rules to declare extra files
that are used by the compiler. In rust's case this happens commonly
with `include_str!()`.
Other compilers like javac or aapt2 don't often reach out to other
files, so it's not as neccessary. But they will follow symlinks.
We're making a change to only include symlinks themselves in sbox
sandboxes, and the targets of the symlinks must be listed
explicitly. For this, we need compile_data to list the targets
of symlinks.
Bug: 307824623
Test: m out/soong/.intermediates/frameworks/base/tools/aapt2/integration-tests/SymlinkTest/AaptSymlinkTest/android_common/lint/lint-baseline.xml with the symlink change
Change-Id: I33eb9cbe4b6eb25e3f33ea0ac9dade88c3d4a624
Also downgrade the new UseSdkSuppress check from error to warning.
And temporarily downgrades FlaggedApi from error to warning until
existing violations are resolved.
Test: The build
Bug: 303434307
Change-Id: Id7802621d567815470dee1aeb815abe214f098cd
This change adds an overrideable property flags_packages to android_app,
which is used to list the aconfig_declarations module names that the app
depends on. The build action of android_app is modified to pass all
flags text file provided by the aconfig_declarations to aapt2 link as
--feature-flags arguments.
Test: m nothing --no-skip-soong-tests
Bug: 306024510
Change-Id: I4924f88b9954950cc1936a472cd7ac70f41add5d
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 Cl adds a new rule to Soong to generate code ownership metadata. Also, this CL adds a provider in the Java SDK library to provide generated source files to the Code_metadata rule. Will add providers to other libraries in the future changes.
Bug: 296873595
Change-Id: Ic2e43aa9b161231fea4416d1f0d36b778361d7c5
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
