* changes:
Remove srcs_lib and srcs_lib_whitelist_pkgs
Remove the automatic dependency to framework-res.apk for R/Manifest
Prepare to be able to put framework-res in srcs
* changes:
Remove srcs_lib and srcs_lib_whitelist_pkgs
Remove the automatic dependency to framework-res.apk for R/Manifest
Prepare to be able to put framework-res in srcs
There are two parts to this change.
Normalization: If a module specifies 'java_version: "9"', this is now
normalized into 'java_version: "1.9"'. Users might reasonably assume
that "9" should be valid, since javac treats them as synonyms (and, in
fact, the javac documentation lists "9" as a valid value but doesn't
mention "1.9"). However, the soong code that triggers JPMS support
(i.e. setting -system rather than --boot-class-path) looks for the
string "1.9", so prior to this change modules specifying "9" would
fail with a confusing error ('javac: option --boot-class-path not
allowed with target 1.9'). Normalizing "9" to "1.9" fixes this. (The
change normalizes the other supported values, too, for consistency.)
Validation: This change also makes the build fail-fast with a clear
error message for invalid values. In particular, modules specifying
"10" or "11" fail with an explicit message that this is not supported,
in anticipation of the switch to OpenJDK 11. Prior to this change,
modules setting those values would get the confusing
'--boot-class-path not allowed' error described about since JPMS
support would not be triggered. (That could be fixed by changing the
JPMS logic to trigger on "10" and "11", but that would be dangerous
since support in the rest of the system for v54 and v55 class files is
unproven: it is better to fail explicitly.) (This change also makes it
fail-fast for any unrecognized values.)
Test: make java
Test: make targets with java_version set to "1.8", "8", "1.9", and "9", all succeed ("9" fails without this change)
Test: make targets with java_version set to "10" and "11", fail with the explicit "not supported" message
Test: make target with java_version set to "xxx", fails fast with the "unrecognized" message
Bug: 131683177
Change-Id: I2f5eb496c29d7736c68c01401c3f0967aeae99fc
This prevents SystemConfig from trying to read them. Also removed ' ' prefix+postfix when creating an empty config.
Bug: 140074769
Bug: 140092095
Test: Flashed device, no more "SystemConfig: Tag compat-change is unknown..." warnings in logcat
Change-Id: I374826526fe3e4555474688b65a0be7253c6dd8c
They are no longer used. Sources are provided via filegroup.
Also removing the SrcDependency interface as it is no longer used.
Bug: 135922046
Test: m
Merged-In: I81f9614d20fbdd2f7d18340d6dbdb592e7acde06
(cherry picked from commit fa21cba64a)
Change-Id: I81f9614d20fbdd2f7d18340d6dbdb592e7acde06
framework-minus-apex and framework-annotation-proc had automatic
dependency to framework-res.apk to get the generated R.java and
Manifest.java as their inputs.
That is no longer needed as the sources are fed from framework-srcs
filegroup.
Bug: 70046217
Test: m
Merged-In: Ibb03db01c177d6e908cbbdf91f18be8744f02c03
(cherry picked from commit 8cc55bdffe)
Change-Id: Ibb03db01c177d6e908cbbdf91f18be8744f02c03
This change introduces two changes required to put
framework-res explicitly in srcs property, without relying on the build
system to specially add framework-res as a dependency to
framework-minus-apex, etc.
1) R.java and Manifest.java generated from aapt were packaged to the file
R.jar directly under the gen directory. With this change, the file
becomes android/R.srcjar under the gen directory.
2) android_app module now overrides OutputFileProducer interface so that
it can recognize "{.aapt.srcjar}" tag to reference the generated srcjar file.
Being able to put framework-res in srcs allows us to pass all the source
files (both in the source tree and the ones generates) via a filegroup.
Previously, the source files could only be passed via the java_library
module type. This caused a circular dependency problem when the java
library was used as an input (src_libs) of the droiddoc module. Using
filegroup eliminates the circular dependency.
Bug: 70046217
Test: m
Merged-In: I9ab6116bcc6fa3da60933d427575463b05ae69b4
(cherry picked from commit 94f37f33ed)
Change-Id: I9ab6116bcc6fa3da60933d427575463b05ae69b4
They are no longer used. Sources are provided via filegroup.
Also removing the SrcDependency interface as it is no longer used.
Bug: 135922046
Test: m
Merged-In: I81f9614d20fbdd2f7d18340d6dbdb592e7acde06
(cherry picked from commit fa21cba64a)
Change-Id: I81f9614d20fbdd2f7d18340d6dbdb592e7acde06
framework-minus-apex and framework-annotation-proc had automatic
dependency to framework-res.apk to get the generated R.java and
Manifest.java as their inputs.
That is no longer needed as the sources are fed from framework-srcs
filegroup.
Bug: 70046217
Test: m
Merged-In: Ibb03db01c177d6e908cbbdf91f18be8744f02c03
(cherry picked from commit 8cc55bdffe)
Change-Id: Ibb03db01c177d6e908cbbdf91f18be8744f02c03
This change introduces two changes required to put
framework-res explicitly in srcs property, without relying on the build
system to specially add framework-res as a dependency to
framework-minus-apex, etc.
1) R.java and Manifest.java generated from aapt were packaged to the file
R.jar directly under the gen directory. With this change, the file
becomes android/R.srcjar under the gen directory.
2) android_app module now overrides OutputFileProducer interface so that
it can recognize "{.aapt.srcjar}" tag to reference the generated srcjar file.
Being able to put framework-res in srcs allows us to pass all the source
files (both in the source tree and the ones generates) via a filegroup.
Previously, the source files could only be passed via the java_library
module type. This caused a circular dependency problem when the java
library was used as an input (src_libs) of the droiddoc module. Using
filegroup eliminates the circular dependency.
Bug: 70046217
Test: m
Merged-In: I9ab6116bcc6fa3da60933d427575463b05ae69b4
(cherry picked from commit 94f37f33ed)
Change-Id: I9ab6116bcc6fa3da60933d427575463b05ae69b4
This includes a few changes that make AndroidMkEntries more resemble
AndroidMkData, especially in terms of how extra entries are added.
Most importantly it can now have multiple custom functions.
Test: Soong tests
Change-Id: Ibf9102624d16d0c1c9894a2794fc7c797bb34c9a
This change removes srcs_lib_whitelist_dirs which was used to let
droiddoc to know the base directories for the AIDL/Java source files.
Instead, the base directories are given via the path property of the
filegroup modules.
This change also includes a fix that the base directories from all
filegroup modules listed in srcs are used as the import paths for the
AIDL compiler. This removes the need to have aidl.[local_]include_dirs.
Bug: 70046217
Test: m
Exempt-From-Owner-Approval: Approved internally
Merged-In: I62ff2a7dd3943d9a3d95d91c36a30fd44ea467d2
(cherry picked from commit f79334d95c)
Change-Id: I62ff2a7dd3943d9a3d95d91c36a30fd44ea467d2
This change removes srcs_lib_whitelist_dirs which was used to let
droiddoc to know the base directories for the AIDL/Java source files.
Instead, the base directories are given via the path property of the
filegroup modules.
This change also includes a fix that the base directories from all
filegroup modules listed in srcs are used as the import paths for the
AIDL compiler. This removes the need to have aidl.[local_]include_dirs.
Bug: 70046217
Test: m
Exempt-From-Owner-Approval: Approved internally
Merged-In: I62ff2a7dd3943d9a3d95d91c36a30fd44ea467d2
(cherry picked from commit f79334d95c)
Change-Id: I62ff2a7dd3943d9a3d95d91c36a30fd44ea467d2
sysprop_library now checks the API stability itself, cutting dependency
on java_sdk_library. Under the directory {module_dir}/api,
{module_name}-current.txt and {module_name}-latest.txt hold API
signatures.
When sysprop_library is built, or a user run "m {module_name}-check-api"
command, API check is performed. First, current.txt must have exactly
same signature with built sysprop_library module. Second, current.txt
must be compatible with latest.txt.
Build system emits a handy error message to generate/update those API
files, in case of missing or mismatching. Also, a script file for
freezing API files is introduced.
Bug: 131637873
Test: 1) m && boot blueline
Test: 2) m {sysprop_library} performs API check
Test: 3) manual test for check-api, freezing api
Change-Id: I9d25f5dc64299e666527ca8e23d7233966901c4e
Merged-In: I9d25f5dc64299e666527ca8e23d7233966901c4e
Merged-In: Ib7ad4f17e82c90da5ef3f80e2ab88c0b53112c60
(cherry picked from commit 093f0eb133)
sysprop_library now checks the API stability itself, cutting dependency
on java_sdk_library. Under the directory {module_dir}/api,
{module_name}-current.txt and {module_name}-latest.txt hold API
signatures.
When sysprop_library is built, or a user run "m {module_name}-check-api"
command, API check is performed. First, current.txt must have exactly
same signature with built sysprop_library module. Second, current.txt
must be compatible with latest.txt.
Build system emits a handy error message to generate/update those API
files, in case of missing or mismatching. Also, a script file for
freezing API files is introduced.
Bug: 131637873
Test: 1) m && boot blueline
Test: 2) m {sysprop_library} performs API check
Test: 3) manual test for check-api, freezing api
Change-Id: I9d25f5dc64299e666527ca8e23d7233966901c4e
Merged-In: I9d25f5dc64299e666527ca8e23d7233966901c4e
(cherry picked from commit 093f0eb133)
Treat proto.type: "javamicro" as a plugin by explicitly passing the
path to protoc-gen-javamicro. This allows removing the javamicro
customizations from the core plugin code.
Bug: 117607748
Test: m checkbuild
Change-Id: I703a8c1b788d77dcf6c656e79cab1c02171aa94e
