Commit graph

30 commits

Author SHA1 Message Date
Jiyong Park
50146e9c8e sdk_version: "module_current" is supported
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
2020-01-31 23:01:34 +09:00
Jiyong Park
6a927c4e6a Abstract sdk_version string using sdkSpec type
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
2020-01-25 21:56:43 +09:00
Baligh Uddin
cf0bba7a30 Merge "Revert "Revert "Allow codename.fingerprint format for minSdkVersion""" 2020-01-25 04:12:30 +00:00
Baligh Uddin
f62013736a Revert "Revert "Allow codename.fingerprint format for minSdkVersion""
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
2020-01-24 23:15:44 +00:00
Jaewoong Jung
9befb0c326 Add runtime_resource_overlay.
Fixes: 119811120
Test: app_test.go
Test: Converted and built IconPackFilledSystemUIOverlay
Change-Id: I71841148c25f820ba829f751a201d2c771c8bd20
2020-01-23 14:24:41 -08:00
Pete Gillin
230e241f58 Revert "Allow codename.fingerprint format for minSdkVersion"
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
2020-01-21 13:44:50 +00:00
Baligh Uddin
014a85712d Allow codename.fingerprint format for minSdkVersion
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
2020-01-20 07:46:12 -08:00
Colin Cross
07c8856904 Delay invalid sdk_version error for AllowMissingDependencies
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
2020-01-07 20:14:14 +00:00
Colin Cross
1184b647d5 Add EarlyModuleContext for LoadHookContext
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
2020-01-04 08:40:55 -08:00
Colin Cross
6cef481ee7 Use java language 1.9 for sdk_version: "current"
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
2019-10-29 13:35:39 -07:00
Colin Cross
6d8d8c6a91 Remove special case for sdk_version: "none"
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
2019-10-29 13:35:39 -07:00
Paul Duffin
e25c644f1e Add system_modules to droidstubs
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
2019-10-11 16:38:14 +01:00
Elliott Hughes
34b49d1402 Use toybox md5sum instead of md5 on macOS.
Test: builds locally
Change-Id: I04aa52de96e0525a44331cb0c057a8e18a95891d
2019-09-06 14:42:24 -07:00
Colin Cross
ee94d6ab14 Add RuleBuilder helper functions for built and prebuilt tools
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
2019-07-11 13:05:19 -07:00
Paul Duffin
7aae6e7794 core_current does not include framework libraries
Bug: 134566750
Test: m droid
Change-Id: I9496a121e28fabe0c60959ac8ccea60ec4b58544
2019-06-26 14:38:00 +01:00
Paul Duffin
735d03c65c Remove unused condition in decodeSdkDep(...)
The string "core.platform.api.stubs" is never passed to the toModule
function since change I6bb6c1a0ea24437c8253dc5d8fabd37edabc9d3e.

Bug: 134566750
Test: m droid
Change-Id: Ia425a433cd762bba30be72e837fa4199580e5b6c
2019-06-26 14:37:31 +01:00
Paul Duffin
5c2f963a1d Remove the no_framework_libs property
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
2019-06-24 16:03:56 +01:00
Paul Duffin
50c217c744 Add sdk_version:"core_platform" to replace no_framework_libs:true
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
2019-06-17 13:17:35 +01:00
Paul Duffin
a3d0986cfc Remove the no_standard_libs property
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
2019-06-17 11:21:39 +01:00
Paul Duffin
52d398a841 Add sdk_version:"none" to replace no_standard_libs:true
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
2019-06-13 19:15:10 +01:00
Paul Duffin
250e6198d4 Make sdkDep/decodeSdkDep the source of truth about the sdk
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.
2019-06-13 15:16:32 +01:00
Colin Cross
0ea8ba82fc Consolidate baseContext, BaseContext, and BaseModuleContext
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
2019-06-06 20:01:31 -07:00
Neil Fuller
ba88c41274 Use correct system_modules with core.current.stubs
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
2019-06-06 14:15:00 +01:00
Jiyong Park
71b519d6ce Set default target SDK version for APEX
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
2019-04-19 14:45:41 +09:00
Colin Cross
109328714f Allow codename.fingerprint format for targetSdkVersion
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
2019-04-18 16:05:37 -07:00
Colin Cross
3047fa23da Build framework.aidl in Soong
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
2019-04-18 13:51:58 -07:00
Colin Cross
ff0daf4ccf Fix sdk_version: "system_current" when Platform_sdk_final=true
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
2019-04-02 23:18:30 +00:00
Colin Cross
571cccfcbc Prepare for a type-safe OnceKey
Add an opaque OnceKey type and use it for all calls to Once in
build/soong.  A future patch will convert the arguments to
Once* to OnceKey once users outside build/soong have been updated.

Test: onceper_test.go
Change-Id: Ifcb338e6e603e804e507203c9508d30ffb2df966
2019-02-06 01:52:41 +00:00
Colin Cross
98fd57460f Use latest SDK version for current in PDK builds
PDK builds need to use the latest SDK version instead of "current"
to match the behavior of Make.

Bug: 118634643
Test: sdk_test.go
Change-Id: Ice10d0ccb4066f27ce5839fc96a4026510057121
2019-01-10 07:09:35 +00:00
Colin Cross
fb6d781202 Split out sdk.go from java.go
Split out SDK handling functions from java.go to sdk.go and tests
from java_test.go to sdk.go.

Test: sdk_test.go
Change-Id: I83ef48cbe5230572c1d4ecc0e89021d2f7c71b76
2019-01-10 07:09:29 +00:00