This change removes the java_sdk_library to submodule calculus logic,
i.e. the "magic". The "magic" is no longer being used, as all existing
usages have been fixed to specify the submodule that it actually depends
on.
Test: m nothing --no-skip-soong-tests
Bug: 368144555
Change-Id: I653bd734959c3366a40f003274c921b012be24ca
Instead, the module should specify the submodule it actually depends on.
This is a prereq change to removing the java_sdk_library "magic"
Test: m nothing --no-skip-soong-tests
Bug: 366069293
Change-Id: I9137c079afc7abf201e597e323ae7de415eea0dc
So that we can decide the configuration after defaults are evaluated.
Instead, pass the enabled property on to submodules.
Bug: 361816274
Test: m nothing --no-skip-soong-tests
Change-Id: I853d557ed022f7434287cea0a2a19e684b59e145
The property was introduced as an interim solution, and is currently
unused.
Test: m nothing --no-skip-soong-tests
Bug: 366071058
Change-Id: I57abdb64fabdb34fbbd1190851bc528dbb88c7f8
Pass the name of Soong's checkbuild target for each module to
Make so that it can depend on it from the main checkbuild rule.
This will give better control over which files get built, allowing
checkbuild to skip the jar combining step when transitive classpath
jars are enabled. The per-module checkbuild targets are passed to
make instead of added directly as a dependency of checkbuild in order
to maintain the existing behavior of only building modules exposed
to make in checkbuild.
Also tweak the existing calls to CheckbuildFile and add
InstallFileWithoutCheckbuild to match the files that are
in the Make-based checkbuild.
Bug: 308016794
Test: m checkbuild
Change-Id: Ic5140819381d58f4d00f23a7a12447950c4cf268
This change introduces a method to detect violating inter-container
dependencies between modules. The method is run in
`ModuleBase.GenerateBuildActions`, after the container info provider is
set. Given that the provider of the direct dependencies would have been
set at this time, the method utilizes this information to determine
the violations, which are introduced in https://r.android.com/3141104.
Note that this enforcement does not turn all inter-container
dependencies as errors. Instead, it will only turn dependencies that
matches the pre-defined violations into errors. Even if the dependency
matches the violation, an error will not be thrown if the dependency
satisfies any of the exception functions (e.g. the dependent module is
stubs, or the two modules belong to the same apexes).
Test: m nothing --no-skip-soong-tests
Bug: 338660802
Change-Id: Ib9ddc0761fa46f1309b1a1a4f759d9a4e04fd70e
This reverts commit bb678f82d6.
Reason for revert: Droidmonitor created revert due to b/362639013. Will be verifying through ABTD before submission.
Change-Id: I1dcb71672eeb44a17cf176d3731bcaf9aaf81edf
The IDEInfo() methods read properties. To make those properties
configurable, we need a context to evaluate them with.
Bug: 362579941
Test: m nothing --no-skip-soong-tests
Change-Id: I26d4b7084439b3006e50b02277298f74a929e1aa
This change introduces a method to detect violating inter-container
dependencies between modules. The method is run in
`ModuleBase.GenerateBuildActions`, after the container info provider is
set. Given that the provider of the direct dependencies would have been
set at this time, the method utilizes this information to determine
the violations, which are introduced in https://r.android.com/3141104.
Note that this enforcement does not turn all inter-container
dependencies as errors. Instead, it will only turn dependencies that
matches the pre-defined violations into errors. Even if the dependency
matches the violation, an error will not be thrown if the dependency
satisfies any of the exception functions (e.g. the dependent module is
stubs, or the two modules belong to the same apexes).
Test: m nothing --no-skip-soong-tests
Bug: 338660802
Change-Id: I36e9cd956c5a076a53635be0c6ff27f77725516e
Currently, the (from-text) stub jar depends on the check api timestamp
of the same api scope droidstubs. However, building the top level
sdk_library phony target does not trigger check api, as the top level
java_sdk_library "depends" on the stub submodules but the top level
phony target does not build the stubs generated by its submodule, nor
the top level java_sdk_library generate any output files.
In order to support the user's workflow of observing checkapi failure
after modifying the api by running `m <java_sdk_library name>`, this
change adds the paths to the stub jars as dependencies as the top level
java_sdk_library phony target.
Bug: 234113632
Test: modify source file api, run m <java_sdk_library name> and observe checkapi failure
Change-Id: Iccd42c8ef7d5de20f71c347455c1a90d83a6c70c
This change prevents non-stub modules with stub suffix from being
determined as the stub module, and instead makes the check more robust
by determining the condition based on the user-hidden
`Stub_contributing_api` property, which is only set for the stub
submodules generated by `java_sdk_library`.
Test: m nothing --no-skip-soong-tests
Bug: 361179822
Change-Id: I28a599c5b4fe1e8460e60580c0535aaf19e39ba3
libraries and apps can depend on the top-level java_sdk_library like
such
```
java_library {
name: "mylib",
libs: ["somesdklib"],
}
```
and soong will automatically resolve mylib's classpath to either the
stub or impl library based on the api container these libraries are in.
Since the top-level java_sdk_library has no compilation actions, code
completion of `mylib` is not feasible today via
`module_bp_java_deps.json`. This CL adds support for this code
completion by registering the .impl (or public stubs) as a transtive
dependency of `mylib`.
The implication of this change is that implementation symbols of the sdk
library will be surfaced during code-completion of mylib, even when
mylib is in a different container. Long term, this should go away when
all the library dependencies are made explicit in Android.bp files.
Test: go build ./java
Test: verified that symbols of android.car.builtin (a java_sdk_library)
can be resolved with the repro instructions in b/356572093#comment5
Bug: 356572093
Bug: 358613520
Change-Id: Ia3887bae34bbd25b8c6346f43602835da32af84a
Revert submission 2982300-java_api_library_non_sdk
Reason for revert: DroidMonitor: Potential culprit for b/357648959 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Reverted changes: /q/submissionid:2982300-java_api_library_non_sdk
Change-Id: I5ef7afd9ec3e10ea99f82d02172843ad9b2cfda9
This change allows from-text stubs to be generated for all
java_sdk_library modules, unlike how it is currently limited to the
modules that contribute to the api surfaces (i.e. the SDK).
This change accomplish this by modifying the dependency of the
from-text stubs generation, so that the sdk_library generated from-text
stubs generating java_api_library modules no longer depend on the full
api surface stubs, but generate the stubs in the module level, and
combined later to generate the full api surface stubs.
This change also removes the java_api_library modules defined in
core-libraries/Android.bp, which are passed to generate the system
modules. Given that the from-text vs from-source toggle is done within
the java_sdk_library stubs level, these modules no longer need to exist.
Implementation details:
- Allow sdk_version to be specified in java_api_library modules. For
java_sdk_library-generated java_api_library modules, they inherit that
of the sdk_library module. Some java_sdk_library modules that do not
contribute to the api surface are allowed to set sdk_version to
something other than "none" or "core".
- Implement java_api_library to implement `SdkContext`. This allows
java_api_library to collect required deps from sdk_version (classpath,
bootclasspath, system modules), and pass the collected jars when
generating the stubs srcjar in metalava and compiling the stubs srcjar
in javac.
- Remove hardcoded list of sdk_library modules that are allowed to
genereate stubs from the api signature files, and allow from-text
stubs generation by default. Modules that are not able to generate
stubs from the api signature files are specified by setting the newly
introduced `Build_from_text_stubs` property to `false`.
Test: ENABLE_HIDDENAPI_FLAGS=true m
Bug: 327507877
Change-Id: Ia35d2f3cf9fae48fc8c4bd99a84ae18d7c0e7bee
Note that this property is currently a no-op. This change is submitted
separately in order to prevent submitting the entire topic in git_main
to mark a main-only module with this property.
Test: m nothing
Bug: 327507877
Change-Id: I62c2e3522bf9d0c5f7955e7c9bd2e0f66458e48c
java_sdk_library's "magic" will always resolve to stubs when either of
the following conditions are met:
- the module sets `api_only` property to "true": this signifies that
the module does not create an implementation library, thus the "magic"
always returns stubs
- the module sets `default_to_stubs` property set to "true": this
signifies that the reverse dependencies outside of the same apex will
always get the stubs, even when the rdep does not specify the
sdk_version.
This change utilize this information and mark the top level sdk_library
as a stubs module when any of the above conditions are met, in order to
minimize the false positives in container violation errors.
Test: Run container enforcement and observe results
Bug: 354029496
Change-Id: I04b52c5662f635ab1837eb33a39f187ae8998238
The `--hide-package` option that this uses is being removed from
Metalava. The same functionality can more easily be achieved by simply
creating a `package.html` or preferably `package-info.java` that
contains `@hide` in their `<body>` tag or Javadoc respectively.
Bug: 351991463
Test: m checkapi
Change-Id: If7ea2449d1bddc0df460c285bf7959dbf9409b04
In the context of incremental soong, the output files
inter-module-communication will be through OutputFilesProvider.
The OutputFileProducer interface will be deprecated.
Test: CI
Bug: 339477385
Change-Id: I3c9f0b766325dd490bc903dc65259c3953d34606
This change removes the unused `apiScope.apiFileTag` and its
`depInfoExtractor` function.
Test: m nothing --no-skip-soong-tests
Change-Id: I640bee3a188be03742559e31ce4fbc4475dbd3ba
Currently, extractStubsSourceInfoFromDep always return the "everything"
stub artifacts. This change modifies such behavior so that the
"exportable" artifacts are set when
`RELEASE_HIDDEN_API_EXPORTABLE_STUBS` build flag is set to true.
Test: m nothing --no-skip-soong-tests
Bug: 348370901
Change-Id: I1cf0ff7a63c8a580c3553a817ca303d6e8734a2a
When creating the lint reports for the mainline modules, the apex
build rule collects the lint artifacts from its dependencies. The
artifacts for Java modules are collected using the two methods:
- `JacocoReportClassesFile()`
- `LintDepSets()`
https://r.android.com/3079425 has removed the compilation actions from
the top level sdk library, but given that BCPF and SSCPF still list the
top level sdk library as the dependency, the lint artifacts are
collected from the top level sdk library. The aforementioned change
resolved this discrepancy by the top level sdk library referencing the
build artifacts of the implementation library.
However, `LintDepSet()` was mistakenly left out, leading to the lint
xml file of the sdk library not being correctly included in the apex
lint artifacts. This change fixes such discrepancy by the top level sdk
library correctly referencing the lint dep set output of the
implementation library.
Bug: 339267677
Test: TARGET_RELEASE=ap3a TARGET_BUILD_VARIANT=userdebug
PRODUCT=mainline_modules_x86_64 MODULE_RELEASED_PLATFORM=U
COVERAGE_MODULES="configinfrastructure"
./vendor/google/build/build_unbundled_coverage_mainline_module.sh \
inspect ninja command and verify that the lint xml files of the impl lib
is included in com.android.configinfrastructure module lint-report-xml.zip
Change-Id: I5c397c8782bad3bc21524f9ef7991cfdda4cdda1
Permissions of apex variants of shared java sdk libraries should use the
base apex name (com.android.foo) and not the override apex name
(com.mycompany.android.foo). The override apex name started being used
when separate variants were created for override apex transitive deps
(https://r.android.com/3083813)
Bug: 346486531
Test: m com.google.android.ipsec
Test: verified that
out/target/product/<product>/apex/com.google.android.ipsec/etc/permissions/android.net.ipsec.ike.xml
contains /apex/com.androiqd.ipsec/javalib/android.net.ipsec.ike.jar #
previously it contained com.google.android.ipsec
Test: https://android-build.corp.google.com/builds/abtd/run/L59900030004679761
Change-Id: I863170d78efa017bef5e4ece3b1471f74ba84b0c
In the context of incremental soong, the output files
inter-module-communication will be through OutputFilesProvider.
The OutputFileProducer interface will be deprecated.
These module types are included in this change:
linker_config
llndk_libraries_txt
sanitizer_libraries_txt
java_sdk_library_xml
vndksp_libraries_txt
vndkcore_libraries_txt
vndkprivate_libraries_txt
vndkpublic_libraries_txt
Test: CI
Bug: 339477385
Change-Id: I35575bbad137df5ff8001db9a61ba5b3d13eaa6d
This change modifies the contents of the generated Android.bp files so
that when generating a snapshot on a older platform, the "exportable"
modules are removed from the bp files, as the "exportable" modules are
first introduced in V and do not exist in older platforms.
Bug: 345162614
Test: ABTD
Change-Id: I2dba51b98deec7805bd796647a66981f237c55a9
`UpdateDirectlyInAnyApex` is used to propagate the ApexProperties
`DirectlyInAnyApex` and `InAnyApex` to the direct dependencies of the
direct dependencies of an apex bundle. In other words, this will be
propagated only to two-levels max dependency from the apex bundle.
However, the implementation library of the sdk library can have longer
dependency chain from the apex bundle than two levels:
e.g. apex -> bcpf -> sdk_lib -> sdk_lib impl lib
Therefore, even if the implementation library of the sdk library is
registered as a dependency using the "CopyDirectlyInAnyApexTag"
dependency tag, the ApexProperties would not be propagated to the
implementation library. In order to resolve this issue and recognize
the implementation library to be directly in apex and allow
instrumentation for the implementation library, this change proposes
propagating `DirectlyInAnyApex` and `InAnyApex` to transitive
dependencies on top of direct dependencies.
Test: DIST_DIR=dist_dir TARGET_BUILD_VARIANT=userdebug PRODUCT=mainline_modules_x86_64 COVERAGE_MODULES="uwb" ./vendor/google/build/build_unbundled_coverage_mainline_module.sh && \
unzip -l out/target/product/module_x86_64/jacoco-report-classes-all.jar and ensure that framework-uwb is included
Bug: 341170242
Change-Id: I27d7a74f6e5bc3e0a044d13c619f4897b6b2eb57
To include a sdk library impl and a permission xml for that.
Bug: 340365498
Test: m aosp_cf_system_x86_64 && check if there is a sdk lib impl and
permission xml
Change-Id: I10190fb9d398b6249efd6fe50b204e328250f23f
Currently, the implementation library of the java_sdk_library is always
being instrumented due to the issue described in b/159241638.
With https://r.android.com/3079425, all compilation actions of the
java_sdk_library is delegated to the implementation library.
Consequently, this has caused all java_sdk_library to be instrumented,
leading to coverage builds failing due to double instrumentation (i.e.
instrumenting an already instrumented class file). In order to prevent
such error, this change modifies the property of the implementation
library to not instrument during coverage builds.
This change also copies some additional java library properties from
that of the implementation library to the top level sdk library, in
order to ensure that all non-null androidmk entries are correctly
reflected in that of the sdk library.
Test: lunch husky-trunk_staging-userdebug && EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m droid dist
Bug: 340174053
Bug: 341170242
Change-Id: I9d8f1c190205fa7a827649961ba5222293a945ad
This replaces the global override of min_sdk_version (via
`APEX_GLOBAL_MIN_SDK_VERSION_OVERRIDE`) with an min_sdk_version override
that can be set by each individual soong override_app.
The use case for this are go apps which are only installed in T and
above, even though the base AOSP apexes might be installable on < T
devices.
Test: added a unit test
Bug: 295311875
Change-Id: Ie2e738a6786bb24417c675617f7c78358017c96c
This change modifies the build actions of java_sdk_library module type
so that it does not perform any compilation actions (i.e. does not
create the top level java_sdk_library jar file). Instead, it delegates
the build actions the top level jar file was performing to the
dynamically created ".impl"-suffixed java library module. The build
actions that are delegated to the impl library module include hiddenapi
processing, dexing, and dexpreopt.
This change relands https://r.android.com/3035972. Implementation
changes from the original change:
- "all_apex_contributions" is added as a dependecy to the implementation
library modules where the parent sdk_library module has a prebuilt
equivalent. This allows the source apex variant to be hidden from make
when the prebuilt is active.
Test: patch in internal main, lunch barbet-ap2a-userdebug && m nothing
Test: m nothing --no-skip-soong-tests
Bug: 332785297
Change-Id: I017938e5567aef82e428e7ceb557d9c9090e0257
This allows using select statements with it.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I6f3efaaa3d82505e38a91ee4ba0e18e404360191
Merged-In: If355d24506e3f117d27b21442a6c02bca3402dc7
Bug: 333311683
Test: build android.bp system image and then check if there is
permission xml file for sdk_library
Change-Id: If5ac1975a7db10d85a1b11c1cd666051e3da546e
This change supports passing multiple last api files to metalava,
instead of emitting an error when multiple files are passed as inputs.
The last api file providing modules are filegroups or genrule modules
that output exactly one output file. This change modifies that behavior
so that the filegroups can output multiple api files.
The last api file providing modules are (mostly) generated from the
`prebuilt_apis` sdk module. However, these modules only provide a single
api scope txt files (e.g. system api scope last api file filegroup
would only provide last system api file, not system + public). This
change modifies `prebuilt_apis` by generating "combine" filegroup
modules, that include api files of the subset api scopes as well.
The ordering of the files are handled when generating the combined api
filegroup modules, and droidstubs module does not check whether the
passed api files are in order from the narrowest api scope to the widest
api scope.
Submission of this change will be done once metalava fully supports
handling multiple api files input for api lint and nullness migration.
Test: m nothing
Bug: 321827591
Change-Id: I2066e7ceb7ee7c6d0fd87cd43bfd08db906d4b8f
aosp/2984037 disabled dexperopt of the source apex system server jars
when prebuilts are selected. This was done to prevent duplicate
installation and dex2oat deps.
AOSP art has some additional variants like com.android.art.debug. In
source builds, this apex should contain service-art.jar and
service-art.jar.prof (a dexpeopt artifact). We have a test to check this
(`art_apex_test.py`). If we disable dexpreopt of source sdlib when
prebuilts are selected, this test needs to be disabled. This is the
behavior at ToT.
This CL changes the behavior to enable running this test even when
com.google.android.art prebuilt is active in a specific release
configuraiton. To prevent collisions that prompted aosp/2984037, this CL
special-cases the installation and dex2oat rules instead of disabling
dexpreopt of the source sdklib altogether.
b/331665856 tracks the principled solution to prevent duplicate
dexpreopt rules.
Implementation:
Add a new copyApexSystemServerJarDex arg to GenerateDexpreoptRule API.
If true, the dexjar file will be copied to
out/soong/system_server_jars/. For soong modules, the value of this will
be the inverse of disableSourceApexVariant. Since none of the apex
system server jars are in make, this will be a noop in dexpreopt_gen
Bug: 331665856
Test: modified trunk_staging.scl locally to select
art.google.contributions.prebuilt; mmma art; (with the sibling CL in
topic)
Change-Id: Idb59e424f83d126cdc8b1671dde358745979bd8d
Use the `WriteFileRule` to write the permissions file for shared
libraries instead of generating a custom bash rule.
Test: TH
Change-Id: I904cf0742bfec46ed45ec7801bb9bd3dc3047185
