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
This field in the java/sdk structure was used in two of the many
possible configurations, so it wasn't really a "default". It also
meant that, to understand those configurations, the reader had to know
what was considered the default, which was only possibly by reading
the code in java.go and droiddoc.go which implemented special code
paths when useDefaultLibs was true. By eliminating that setting and
explicitly setting the required values, the code is simpler and easier
to understand.
This change is a straight refactoring, in the sense that the output of
the build should be unchanged.
Regarding the changes to the proguardRaiseTag dependency in java.go:
- This is a noop for anything which had sdkDep.useModule = true prior
to this change, because they all had the same value for
hasFrameworkLibs() and hasStandardLibs().
- This is a noop for anything which had sdkDep.useDefaultLibs = true
prior to this change, because they do not use proguard settings.
- Therefore, it is a noop overall.
- Nevertheless, it is required to make sdkCorePlatform work. Without
this change, such modules would pick up a dependency on framework
libs via the (unused) proguardRaiseTag, which creates a circular
dependency, because this is the sdk_version used when building
framework libs themselves.
Bug: 157640067
Test: m java docs droid
Change-Id: I3a83b5edc1bd48c16b55f6f77e3e710fc8fbd8fa
When sdk_version: "module_current" in an unbundled build, previously
prebuilt/sdk/current/module/android.jar was used. But that path is
wrong; we have prebuilt/sdk/current/module-lib/android.jar for the
module APIs. Fix the mismatch by changing the string name of the module
API from "module" to "module-lib".
Also, "system_server" for system server API is changed to
"system-server" to match with the path
/prebuilts/sdk/current/system-server/.
Bug: N/A
Test: https://android-build.googleplex.com/builds/forrest/run/L86100000601675127
Change-Id: I23e9befbd9592d3b22989c2c8fbf34d434273288
framework.aidl includes the parcelables from the non-updatable
part of the framework as well as the modules. This causes a
dependency cycle when building module stubs:
module_stub -> module_sdk -> framework.aidl -> public_sdk -> module_stub
The module_sdk only includes the the stubs for the non-updatable
part of the framework, so it should also only contain the non-updatable
parcelables. This change creates a framework_non_updatable.aidl with
those parcelables, and updates module_current to use that.
Bug: 144149403
Test: m
Test: m && diff out/soong/framework{,_non_updatable}.aidl
(the diff contains just TestApi + module parcelables)
Change-Id: I224117a0ff695c22d4a4317a51a9b775ed73066b
Merged-In: I224117a0ff695c22d4a4317a51a9b775ed73066b
(cherry picked from commit 85c151c3f3)
Prebuilt SDKs >=30 now contain core-for-system-modules.jar,
convert them to system modules and use them when compiling against
the SDK to allow using javac -source 1.9 -target 1.9.
Bug: 117069453
Test: TestClasspath
Change-Id: Iebadad5980b952ed91c3ffd56cff1ce1827d3247
Merged-In: Iebadad5980b952ed91c3ffd56cff1ce1827d3247
As a follow up, this property will be set to APKs participating in mainline program.
Bug: 153333044
Test: m
Change-Id: I6ea2f3c1d26992259e4e9e6a6d8cecf091d39c43
Include the module_api stubs in system_server one instead of
putting both of these jars on the classpath. Also rename it
to be in line with the other stubs.
Bug: 149293194
Test: m
Exempt-From-Owner-Approval: approved internally
Change-Id: Iead5af4152a49cd59a4fd7afc0312c2f0c872c1e
Merged-In: Iead5af4152a49cd59a4fd7afc0312c2f0c872c1e
(cherry picked from commit bbd78556da)
1. Check if system sdk version of apps from product partition is one of BOARD_SYSTEMSDK_VERSIONS.
2. The logic that check system sdk version doesn't work after aosp/1212908 because it always returns early
Bug: 147711383
Test: m
Test: set sdk_version the version that doesn't exist in BOARD_SYSTEMSDK_VERSIONS, and check if it cannot build
Change-Id: I923477cffbcd9c763ee2deb5e7cce29aa005c715
The new sdk version "system_server_current" is for system server
components that needs to use all public APIs, system APIs, module APIs,
and the system server APIs.
Bug: 146757305
Test: m
Change-Id: I24fd5af010532a110393676607dc90889f2ec17e
module_* is a new API surface for OS modules (e.g. APEXes). It has
slightly bigger API surface than the system_* SDK. Specifically, APIs
with @SystemApi(client=MODULE_LIBRARIES) are added there.
Bug: 146757305
Test: m
Change-Id: I8980e50c0e3a4cd843048e0de1f638e854384f46
The value format that sdk_version (and min_sdk_version, etc.) can have
has consistently evolved and is quite complicated. Furthermore, with the
Mainline module effort, we are expected to have more sdk_versions like
'module-app-current', 'module-lib-current', etc.
The goal of this change is to abstract the various sdk versions, which
are currently represented in string and is parsed in various places,
into a type called sdkSpec, so that adding new sdk veresions becomes
easier than before.
The sdk_version string is now parsed in only one place 'SdkSpecFrom', in
which it is converted into the sdkSpec struct. The struct type provides
several methods that again converts sdkSpec into context-specific
information such as the effective version number, etc.
Bug: 146757305
Bug: 147879031
Test: m
Change-Id: I252f3706544f00ea71c61c23460f07561dd28ab0
This reverts commit 230e241f58.
Reason for revert: This is a revert of a revert. Downstream problem has been fixed and have been validated locally and via Forrest build.
Change-Id: I89c51d25b3adb818ea44a983d0ac681a88790d8c
This reverts commit 014a85712d.
Reason for revert: Caused vendor/google/build/build_mainline_modules.sh to fail with `Error: minSdkVersion (10000) is greater than maxSdkVersion (30)`.
Bug: 130541924
Change-Id: Ifa233bf40a674481d21b61ee816c5fdde8201080
Use codename.fingerprint format for minSdkVersion if it is unset
in the manifest and
UNBUNDLED_BUILD_TARGET_SDK_WITH_API_FINGERPRINT=true.
Using a utility function in sdk.go to check whether to apply
api.fingerprint.
BUG: 130541924
Change-Id: I748a25c419033bf54b63171d334644fcd0ecc78f
Unbundled builds set AllowMissingDependencies and attempt to use
prebuilts for some jars. Delay the errors for missing jars for
modules with invalid sdk_version values in unbundled builds so
that they only block the build if those modules are built.
Also fix some error messages to show the original sdk_version
value.
Bug: 146513037
Test: m TARGET_BUILD_APPS=Camera2
Change-Id: I1812ef6dc80895f7a2162a8bdbf2c5067755e9a0
Make LoadHookContext embed a new EarlyModuleContext instead of
BaseModuleContext to reduce its API surface in preparation for
moving it to run during parsing instead of mutators.
Test: m checkbuild
Change-Id: I1cd3ff3b636e7e24991a9184d7521903473e505a
Java language was set for 1.8 for anything building against the
current SDK because the stubs were not built in Soong, so the
system modules could not be built. The stubs have been built
in Soong since Iabd32b30954b3f4a6d9a779fde52a032b684807e, but
I5e870c34dd0ebc8ae3f888ec627da590c846a76f missed updating
this TODO.
Use 1.9 when building against the stubs, but continue using
1.8 for unbundled builds until we have prebuilt system modules.
Always use the core-current-stubs-system-modules to avoid
splitting android.* packages between the system modules and
the classpath, which would cause new classes in android.*
packages in classpath jars to be ignored. Add a new
java9Classpath field to sdkDep that will contain the stubs jar
when targeting Java language level 1.9, and plumb it through
to javac and turbine. Rename the modules field to bootclasspath.
Bug: 142896162
Test: m checkbuild
Change-Id: Icfd32d0a863b2303a997c7cf03cb3708aade4724
The dependency handling for sdk_version: "none" (which propagated to
!sdkDep.hasStandardLibs()) was very similar to the normal useModule
case. Combine the cases by making decodeSdkDep set useModule: true
and put the system modules in modules for the sdk_version: "none"
case.
Test: TestClasspath
Change-Id: Icc9ff4d43a38da25cc0e3628be95951d61773ad5
This allows droidstubs to use the same system modules to create the
stubs that will be used to compile them. It improves consistency and
avoids droidstubs having to duplicate the libraries that make up the
system modules on its libs property.
Adds systemModules() to the sdkContext which allows consistent error
checking behavior between droidstubs and java_library.
Bug: 142534789
Test: m checkbuild
Change-Id: Ib2006906d9528a900f16851f50b62152ffb51a1b
Replace the common pattern of:
cmd.Tool(ctx.Config().HostToolPath(ctx, "tool"))
with:
cmd.BuiltTool("tool")
And similarly for PrebuiltBuildTool.
Test: m checkbuild
Change-Id: I7d63188505362c7df6a3b3e7330b4a2cca5a2409
The string "core.platform.api.stubs" is never passed to the toModule
function since change I6bb6c1a0ea24437c8253dc5d8fabd37edabc9d3e.
Bug: 134566750
Test: m droid
Change-Id: Ia425a433cd762bba30be72e837fa4199580e5b6c
Corrects an error message that refers to no_framework_libs.
Removes any tests that use no_framework_libs:true where possible as
there are duplicate tests for sdk_version:"core_platform". Otherwise,
switches them over to use sdk_version:"core_platform".
Bug: 134566750
Test: m droid
Change-Id: I41abe1a49f5c744e3393ca9cdf0c41888f810c9f
Where possible this duplicates any tests that use no_framework_libs:true
with ones that use sdk_version:"core_platform". If not possible (e.g. in the
default targets included in java/testing.go) it switches some to use
sdk_version:"core_platform" to ensure that there is no regression in the
behavior of no_framework_libs:true.
Follow up changes will switch all usages of no_framework_libs:true over
to use sdk_version:"core_platform" at which point no_framework_libs will be
removed.
Bug: 134566750
Test: m droid
Change-Id: I42cb181f628b723c8f32a158ae4752b4c83365ae
Corrects an error message that refers to no_standard_libs.
Removes any tests that use no_standard_libs:true where possible as
there are duplicate tests for sdk_version:"none". Otherwise, switches
them over to use sdk_version:"none".
The androidmk mapping from LOCAL_NO_STANDARD_LIBRARIES to
no_standard_libs has also been removed. There was little point in
updating the tool to map it through to sdk_version:"none" as there are
only a couple of places where it is used, in art's test running mk
targets and in some unbundled packages to work around some limitation
in .mk based build.
Bug: 134566750
Test: m droid
Change-Id: I6413c9b1fe3e63b93753a6a017d2981e32b7e013
Where possible this duplicates any tests that use no_standard_libs:true
with ones that use sdk_version:"none". If not possible (e.g. in the
default targets included in java/testing.go) it switches some to use
sdk_version:"none" to ensure that there is no regression in the
behavior of no_standard_libs:true.
Follow up changes will switch all usages of no_standard_libs:true over
to use sdk_version:"none" at which point no_standard_libs will be
removed.
Bug: 134566750
Test: m droid
Change-Id: I5f0fd3daa980f6b223abe454cba7f25a97a39d7a
Previously, different parts of the build used different sources of
information about the SDK (i.e. the default libraries) against which
a Java module aimed at the device was built. Some used the sdk_version
property, others used the no_standard_libs or no_framework_libs, some
used a combination of all three.
That lead to inconsistent handling in the code, e.g. some parts treated
no_standard_libs: true as implying no_framework_libs: true and others
did not, and also in the build files, e.g. some modules specified
no_framework_libs: true and sdk_version: "system_current" which makes
no sense, or no_standard_libs: true and sdk_version: "core_current"
which are inconsistent.
This is the first step in a refactoring to simplify the sdk selection
process by replacing the no_standard_libs/no_framework_libs properties
with some extra options for the sdk_version property. This change
consists of:
1) Extra functions sdkContext to access the no_standard_libs and
no_framework_libs properties.
2) Extra field/functions in sdkDep to store and access the value of
no_standard_libs/no_framework_libs.
3) Changes to decodeSdkDep(...) to pass the values of the no_...
properties through to the returned sdkDep.
4) Change all code that accesses the no_... properties directly to
call decodeSdkDep(...) to get an sdkDep object and then accessing
the values of the no_... properties from there.
The accessor functions on sdkDep are called has...() rather than
no...() as most callers of the methods invert the value anyway and
!no...() is harder to reason about than has...().
The hasFrameworkLibs() function returns true if and only if
no_standard_libs and no_framework_libs are false. That is consistent
with all but one usage of the no_framework_libs property and that is
not affected by it.
Bug: 134566750
Test: m droid
Change-Id: I196e3304e8bd802fb154e897397b0dd337f868e2
Exempt-From-Owner-Approval: Colin has already given +2 modulo some
minor nits and this blocking other changes.
blueprint.BaseModuleContext is the set of methods available to all
module-specific calls (GenerateBuildActions or mutators). The
android package split the same functionality across baseContext (nee
androidBaseContext), BaseModuleContext, and BaseContext.
Consolidate all of them into android.BaseModuleContext.
Test: m checkbuild
Change-Id: I2d7f5c56fd4424032cb93edff6dc730ff33e4f1e
The system_modules defn used with core.current.stubs
was core-system-modules which doesn't match. Instead,
this change uses core-current-stubs-system-modules.
Test: build
Change-Id: Ifb9e77b02bbb04c1cb39c6b9f97932c20d44d8ba
Target SDK version is used for targeting an APEX to a specific set of
platform builds. Usually, the targeting is unrestricted (in case the
APEX can run on all platforms), or based on platform SDK version (e.g.
28 for P). However, when the platform is under development and SDK is
not finalized, the targeting should be much more fine-grained; the
APEX should be targeted to a very specific build that supports the same
set of APIs that the APEX was built against.
To support that, target sdk version is automatically set by the build
system. When the platform is released or SDK is finalized, the target sdk
version set to the SDK version number. If not, it is set to
<version_code>.<fingerprint> (e.g., Q.123456).
Note that the target sdk version set by the build system is used only
when the target sdk version is not explicitly set in
AndroidManifest.xml.
Bug: 130541924
Test: UNBUNDLED_BUILD_SDKS_FROM_SOURCE=true \
UNBUNDLED_BUILD_TARGET_SDK_WITH_API_FINGERPRINT=true \
TARGET_BUILD_APPS=com.android.tzdata m
build.ninja has --target_sdk_version Q.$$(cat out/soong/api_fingerprint.txt)
Test: aapt dump badging out/dist/com.android.tzdata.apex | grep \
targetSdkVersion shows:
targetSdkVersion:'Q.6ee443d9ad5f0cca7a43cfa97b7fc62a'
Change-Id: I086230d787f01075c28fc3f0163550300fa00212
Use codename.fingerprint format for targetSdkVersion if it is unset
in the manifest and UNBUNDLED_BUILD_TARGET_SDK_WITH_API_FINGERPRINT=true.
Test: manual
Bug: 130541924
Change-Id: I4e3b1274cc32038b00b292dc6d67559eb320e9e4
Move the rules to build framework.aidl into Soong, and use it
when compiling aidl files with sdk_version: "current".
Also fixes incorrectly using the aidl includes exported by the
"framework" module when the proguardRaiseDep dependency was
added.
Bug: 130798034
Test: sdk_test.go
Change-Id: I126adf1d9e7b6acb528875ff62b974ba7ad9a337
When PLATFORM_VERSION_CODENAME is set to REL Platform_sdk_final
becomes true, which causes the return value of sdkVersionToNumber
for "system_current" to a real version number instead of
FutureApiLevel. This enables the check against
PlatformSystemSdkVersions, which doesn't contain "current". Use
the numeric value instead.
Fixes: 129786845
Test: sdk_test.go
Change-Id: If7cf211cc01c5fbf3e3ece3c3f604718a13d5a9b
Dan Albert