Extracted some common code used by visibility_test.go and
neverallow_test.go into a new function CheckErrorsAgainstExpectations
in testing.go.
Bug: 138428610
Test: m nothing
Change-Id: I6996fa52968c387e38b4a67ffa59cd07c2d524e8
Merged-In: Iafbadf12c6ffdc4d9128fcfe7f15792df5cfd020
So far a very basic version.
In case there is a diff, soong will emit an error message with a command
to resolve the diff. Example:
New unexpected files were added to com.android.apex.cts.shim.v3. To fix the build run following command:
system/apex/tools/update_whitelist.sh system/apex/shim/build/default_shim_whitelist.txt out/soong/.intermediates/system/apex/shim/build/com.android.apex.cts.shim.v3/android_common_com.android.apex.cts.shim.v3/com.android.apex.cts.shim.v3-content.txt
Test: m checkbuild
Bug: 139125405
Change-Id: I57e694f394c56105dc7363a684983605c7bf5e7d
Clang is smarter at producing this new warning now, producing far
fewer false positives. Re-enable the diagnostic for Android.
Test: build
Bug: 72331526
Change-Id: Ide827791c51587bceb977ae4116894a8cd620eb1
am: 7153b767a5 -s ours
am skip reason: change_id I81f9614d20fbdd2f7d18340d6dbdb592e7acde06 with SHA1 01d5401dc0 is in history
Change-Id: Id03a7bdf7494b8bb86e5bf252d4cc7f6da7f0815
* 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
sbox will generate a random directory for the output root, and most
tools will encode that directory name in the output target of the
depfile.
So embed the library from dep_fixer into sbox so that it can rewrite the
output filename to a static (reproducible) value. Ninja doesn't care
what that value is, so it's just "outputfile".
Also fix up rule_builder to actually tell sbox about the depfile.
Test: mmma system/iorap; check the contents of:
out/soong/.intermediates/system/iorap/libiorap-binder/android_arm_armv7-a-neon_core_static/gen/aidl/system/iorap/binder/com/google/android/startop/iorap/IIorap.cpp.d
Change-Id: I3640a2e8b0c034f143a35e398a8418a6d621b265
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
The new option will allow the auto-generated test config for cc_test to
include RunCommandTargetPreparer to disable framework before the test
run and re-enable it after the test run.
Bug: 140065309
Test: test hello_world_test with the new option.
Change-Id: If2189e9474f5b11bd0d0471e231a2cae14155389
Adds support to Soong for building rust modules. This currently only
supports x86_64 device and x86 linux host targets. The functionality
is sufficient to build crosvm.
Bug: 136189233
Test: Test module builds.
Test: crosvm builds.
Change-Id: I6ea04615834a6d673578ab10ea1a2eb04259fe09
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
Disables FORTIFY for fuzz target builds. We generally build with a
sanitizer and want the sanitizer to handle the bugs and provide us with
a nice stack trace.
Bug: 140187921
Test: m example_fuzzer && $ANDROID_HOST_OUT/fuzz/example_fuzzer (note
that you get a proper ASan report instead of a fortify crash)
Change-Id: I15a117b26c401a03785fb44c0f796588f366bc55
The header ABI checker is enabled by default for the libs that are used
across APEXes.
Bug: 138219814
Test: m
Change-Id: Ic0e9c5fdfa1259f500d990abc504c452436f3bd7
