Since the name of the java_library generated from sdk_library per api
scope does not depend on the build configuration anymore, all
dependency switching "magic" via android.JavaApiLibraryName() can be
removed.
This change also removes from-text-build-specific test cases, as those
test cases depend on build configurations.
Test: m nothing && m nothing --build-from-text-stub
Bug: 287340610
Change-Id: I3bac35259e0cbaa16432a46cb2b128951c9bc075
This change cleans up references to android.JavaApiLibraryName() so that
rdeps link against "android_*_stubs_current" instead of
"android_*_stubs_current.from-text".
Bug: 284995489
Test: m
Change-Id: Ibdf33b15981317c43e468dbc1657229d54bbd226
APIs to compile lambda are part of art's toolchain api surface.
Generating stubs from .txt files allows us to prune the remaining sdk
dependencies on libcore/ that are not api files
Test: m core-lambda-stubs.from-text
(On top of change containing core.current.stubs.from-text
and turning enabled: true)
Change-Id: I0ab8459b9317cb055a434eb635ba06d38da5b92e
In scope:
- core.current.stubs
- system modules generated for core's public stubs
- system modules generated for core's module_lib stubs
The system modules generated for core_platform api surface will be
handled in aosp/2514755
Test: go build ./java
Change-Id: I34134f79c8ae6e5b218d0b85553de5a748a8cc3f
These hardcoded refs will need to be updated when we start using .txt
stub equivalent (single-tree/multi-tree). Instead of strewing this logic
all over the codebase, create a helper function that contains the
replacement logic. All other places should call this helper function
instead of calculating the name of .txt equivalent soong module by
itself.
(Will do a similar cleanup in build/make)
Test: no change in ninja file
Change-Id: I6bf999eb4aeaba6ac2a44b9016bae4ec8c79ce19
This reverts commit 1fbf7f21a4.
Reason for revert: broke docker image, pinning is incomplete it seems
Change-Id: I7102cb233a4fe5ce0f5a1ead98cfc661c3d82ce5
Revert submission 1944928-default-java11
Reason for revert: Post-submit failures
Reverted Changes:
Ia9a0aa2a4:Setting Java 11 as the default version
Ibf5d10521:Setting Java 11 as the default version
Fixes: 215504708
Fixes: 215502091
Fixes: 215502091
Change-Id: I2f9866deff41406aede24758f6eda5e5808c7f29
Previously, the selection of system modules was duplicated, once for
source and once for prebuilts. This change dedups that by switching the
source code to use the same mechanism as the prebuilts which will ensure
consistent behavior in future.
Bug: 204189791
Test: m nothing
Change-Id: Ia1729017ae332181c95f7b205dab87fb47d43fb8
Renames to core-public-stubs-system-modules so that it is of the format
core-<sdk-kind>-stubs-system-modules.
Bug: 204189791
Test: m nothing
Change-Id: Iac565c940c2ef92be9cc64c0c6b8102a26afe0dd
When building from source the build uses the java system modules for
the public or module APIs as needed. However, previously when building
from prebuilts it would always use the public API. That difference lead
to build failures when building from prebuilts.
This change makes the selection of java system modules when building
from prebuilts consistent with the selection when building from
sources.
As API levels 30 and 31 (which are the only previous releases to
provide system modules) did not provide separate java system modules
for the module-lib API those levels always use the public APIs.
Bug: 204189791
Test: - before applying these change
m TARGET_BUILD_APPS=framework-connectivity
- build fails with compilation error due to missing module APIs
m sdk dist
cp out/dist/system-modules/module-lib/core-for-system-modules.jar prebuilts/sdk/current/module-lib/core-for-system-modules.jar
- apply these changes
m TARGET_BUILD_APPS=framework-connectivity
- build passes as expected
Change-Id: Id113ff014e7892b1009fbcaad89b1ae23a7c3b79
Previously, the fixture preparer for prebuilt_apis would add a
core-for-system-modules.jar file in every API directory even though
currently they only exist in the public API directories.
This change makes the test environment more realistic by only creating
them for the public API. Rather than hard code that into the test code
(which would duplicate the hard coding in the decodeSdkDep func) this
extracts a function that is used by both. That ensures that any changes
to that func will be reflected in both the test and runtime behavior.
Bug: 204189791
Test: m nothing
Change-Id: I346ac9c0dcf407c61de16b6027663a05821bcf62
For the purposes of this change a standard API surface is one of the
following:
* public
* system
* test
* module-lib
* system-server
Test: m droid
Bug: 204189791
Change-Id: I88ee9709430ca455dd6c7d1523ae22f8c22b0b7e
Before this fix, compiling a java_library against sdk_version:
"module_current" can't use the @SystemApi(MODULE_LIBRARIES) provided
by the ART module because the system module "core-current-stubs-system-modules"
contains only the public APIs.
Use the new system module with module lib APIs.
Bug: 183097033
Test: m droid
Change-Id: I274e2710d1ff34e896aa620bfafb4481180c53b5
Previously, there were two approaches used to construct the temporary
path needed by the commitChangeForRestat method and neither was
suitable for general use. One was:
android.PathForOutput(ctx, outputPath.Rel()+".tmp")
The other was:
combinedAidl.ReplaceExtension(ctx, "aidl.tmp")
The first approach would not work if the supplied path had been created
by PathForModuleOut() or similar as it would drop the module directory.
That could lead to the same path being used for multiple rules.
The second approach would not work for files with a different
extension.
The tempPathForRestat combines the two approaches so it can be used
generally with any WritablePath.
Bug: 179354495
Test: verified that the ninja rules that used these files were not
changed by these changes.
Change-Id: I4439dea0a823512c281eeb1366522fb49dceb4e3
Previously, SdkSpec was constructed only from the user string. It didn't
make use of the Config struct where information about the latest stable
SDK version, etc. is recorded. As a result, the build system couldn't
check if the sdk version "current" is referring to the in-development
(i.e. not-yet-frozen) SDK version or the latest stable version.
"current" was always assumed to be in-development (IsPreview() returns
true) even when Platform_sdk_final == true.
As the first step for fixing that, this change requires
android.EarlyModuleContext to be passed when constructing SdkSpec from
the user string.
In the following changes, "current" will be mapped to either
FutureApiLevel (10000) or one of the FinalApiLevels() depending on
whether the platform SDK was finalized or not.
Bug: 175678607
Test: m
Change-Id: Ifea12ebf147ecccf12e7266dd382819806571543
SdkSpec.Version was an int type. Now it becomes ApiLevel type which
is a better abstraction of the version (or api level).
Bug: 1655587
Test: m
Change-Id: I4d67b9b9eae45f653b6af4f5b73da9e091b3dfab
... in preparation for making the handling of sdk versions consistent
across java and cc modules.
Bug: 175678607
Test: m
Change-Id: I598f0454bce9b7320621022115412fbe97403945
Use the ones obtained by merging the ones in non-updatable code, and the
ones exposed in mainline module jars that are part of
SYSTEMSERVERCLASSPATH.
Test: builds
Bug: 177640454
Change-Id: Ib4719d7eb8b76a0e5af79c1270e2f1e344682423
Use the generated txt files as input instead
of globbing for now non-existent files.
Also add the system server api txt to the hash.
Bug: 179807354
Test: verify out/soong/api_fingerprint.txt changes now
Test: verify the command in the ninja file looks ok:
grep api_fingerprint out/soong/build.ninja
Change-Id: I7a49ca134eb93b22537a4f3054285eb15f8c4256
Export information about java dependencies through a Provider
instead of accessing the module directly.
Test: java_test.go
Test: no changes to build.ninja
Change-Id: Ifc5d566bf6f6ebc0ad399e948effaa1ef6a22876
Enable the RuleBuilder and RuleBuilderCommand methods to access
the BuilderContext by passing it to NewRuleBuilder instead of
RuleBuilder.Build.
Test: genrule_test.go
Test: rule_builder_test.go
Test: m checkbuild
Change-Id: I63e6597e19167393876dc2259d6f521363b7dabc
The test case I removed is invalid. The codename has had its int
assigned, but the config claims it is not final.
If this ever does need to be supported it's just a matter of making
sure the Q -> 29 mapping (or whatever) in the finalized codenames map
in android/api_levels.go.
Test: treehugger
Bug: http://b/154667674
Change-Id: I4f42ec2fd4a37750519ee3937938a1c65b6bb1e8
Keeping the int constant around for now as FutureApiLevelInt because
it's still useful in places that haven't adopted ApiLevel yet for
testing if their non-ApiLevel API level is current or not.
Test: treehugger
Bug: http://b/154667674
Change-Id: I47a7012703f41fdeb56f91edf9c83afa93042deb
If BOARD_CURRENT_API_LEVEL_FOR_VENDOR_MODULES has a numeric value,
it replaces "current" or "system_current" with the version which
the flag indicates.
Bug: 163009188
Test: BOARD_CURRENT_API_LEVEL_FOR_VENDOR_MODULES=29 m, and then check if every vendor
java module's sdk_version is 29 if its sdk_version was current.
Change-Id: I17b49b8e02caf2d1bc57b91648d4420f3ad9fcb9
This hasn't worked for a couple years, and continues to bitrot. Just
remove it.
Adds a bpfix rule so that we can eventually remove the
product_variables.pdk definition, which is now always a no-op.
Test: treehugger
Change-Id: I830b54d419b59f6db1d4617b45e61a78234f57a7
Merged-In: I830b54d419b59f6db1d4617b45e61a78234f57a7
Instead of UnbundledBuild, use AlwaysUsePrebuiltSdks
to determine if java modules needs to be built against prebuilt sdks.
And rename UnbundledBuildUsePrebuiltSdks to AlwaysUsePrebuiltSdks to
express its behavior more correctly.(It can be orthgonal to "Unbundled")
Bug: 160390776
Test: TARGET_BUILD_UNBUNDLED_IMAGE=true m vendorimage
Change-Id: I0be7265c1959d8774c295372cd7a9250169f6df9
This change silently decides whether modules which depend on either
sdkPrivate or sdkCorePlatform get the legacy or the stable version of
the core/platform API, based on whether the module's name is on a
hard-coded list or not.
Test: m java
Test: make a target from the list when its entry is commented out, which correctly fails
Bug: 157640067
Change-Id: I15e5a6c2f07e73718803501d705de0d7ab9bec90
Merged-In: I15e5a6c2f07e73718803501d705de0d7ab9bec90
Merged-In: Iaa97ddaa015e8079fcb3426585c5101c7ec9e22a
(cherry picked from commit c0f4373106)
Compared to the effect of the toModule function, this (a) sets
noFrameworkLibs to true, which seems logically correct, and (b) stops
setting java9Classpath, which was redundant since the same stubs are
available in 1.9+ builds via the systemModules setting. (This brings
sdkCore into line with sdkCorePlatform in both cases.)
Test: m art.module.api.annotations
Change-Id: I61a868bc363a3bf174725b78c0a1657021cfe08a
