Relands Ic22603a5c0718b5a21686672a7471f952b4d1017 with a minor
change to track libc++ dependencies for python hosts and after
a fix to an internal genrule that depended on transitively
installed java libraries (ag/13068670).
Soong currently assumes that installed files should depend on
installed files of all transitive dependencies, which results
in extra installed file dependencies through genrules, static
libs, etc.
Annotate dependency tags for dependencies for which the
installed files are necessary such as shared libraries
and JNI libraries.
This avoids extra installed files, and is also a first step
towards genrules using their own copy of tools instead of
the installed copy.
Bug: 124313442
Test: m checkbuild
Test: java.TestBinary
Test: cc.TestInstallSharedLibs
Test: deptag_test.go
Change-Id: I725871249d561428e6f67bba6a7c65b580012b72
Previous extra checks for ErrorProne were added using the plugins
proeprty to get them into the -processorpath argument. This works
fine for java-only modules, but fails for mixed java+kotlin modules
because the processorpath is given to kapt and not javac.
Add a dedicated errorprone.extra_check_modules property (mirroring
the lint.extra_check_modules property), and add that to a separate
processorpath that is used only for errorprone rules and not cleared
when kotlin is used.
Test: TestKapt/errorprone
Change-Id: Id6ef02ce758532d1df8b8d969fad83bb44fe93ab
Previously, setting "sdk_version: none" would have a side effect of
disabling copying to dist by default. This change removes that behavior
and will copy to dist by default unless explicitly specified.
This will have no impact on the dist because all java_sdk_library
modules that relied on the previous behavior to disable copying to
dist have been modified to explicitly disable copying to dist.
Test: lunch sdk-eng && m dist sdk
compare out/dist/apistubs directories before and after this
change to make sure that they have not changed.
Bug: 173715943
Change-Id: I376546b5a8b03de6c944961f7408dad22184fe49
Currently, the no_dist property cannot be set in a .bp file and
defaults to true if the sdk_version property is set to none. That
behavior was added to prevent the output files from the libcore,
conscrypt and icu java_sdk_library modules from being copied to the
dist. It worked because they were the only java_sdk_library modules to
set "sdk_version: none".
Unfortunately, that default behavior is no longer required because
we want to be able to convert "conscrypt" module to a java_sdk_library
and have its public API output files be copied to the dist
automatically. This change allows the no_dist property to be explicitly
set in the .bp file so that those modules that rely on the implicit
behavior can explicitly specify it and allow the default behavior to
be removed.
This change:
* Removes the `blueprint:"mutated"` tag from the No_dist property which
allows it to be specified in a .bp file.
* Only sets the default if the property has not been explicitly
specified in a .bp file.
Test: lunch sdk-eng && m dist sdk
compare out/dist/apistubs directories before and after this
change to make sure that they have not changed.
Bug: 173715943
Change-Id: I8a1c97b690ae05bfe71ea72acc0831fa51aca7e9
This method was added for use in sysprop_library.go but it is no longer
used there. So, this change removes it.
Bug: 173715943
Test: m nothing
Change-Id: I0c2ae8a8d515faf2692eca2aaed63475fdb6a196
The framework-sdkextension java_sdk_library module defines an API for
public, system and module_lib API surfaces but the public API is empty.
The empty public API results in an empty .srcjar being repackaged and
merged into the sdkextension-sdk snapshot and results in no directory
for the public API stubs sources being created. Unfortunately, the
Android.bp file in the snapshot is created by Soong and it does not
know that the public API will be empty and so it creates an Android.bp
file that references the directory into which the stubs sources should
be added but which ends up not existing in the snapshot. Referencing a
non-existent directory causes a build failure.
This change fixes that issue by using PathForModuleSrc with no path
components to get the path to the module directory (which must exist)
and then resolving the module relative local src directory against
that. The local src directory is globbed to find all the files, which
will return an empty set of paths if the directory does not exist.
Finally, the file paths are passed as an rsp file to soong_zip to avoid
exceeding any command line limits.
Many other different approaches were considered:
* Adding a property to the java_sdk_library to indicate that the public
API was actually empty. That would require extra maintenance by
developers and would require some extra checks to be performed after
generating the stubs source to ensure that it was empty which would
complicate the build process.
* Creating a directory with some placeholder file (empty directories
don't work well with git) that would force the creation of the
directory. That file would most likely be created whether the API
was empty or not, would need to be stored in git alongside the source
and could be quite confusing to reviewers.
Bug: 173508731
Test: m nothing - to run new tests
Build sdkextension-sdk, unpack it and then build the .srcjar
files for the public, system and module_lib API surfaces.
Without this change the build failed, reporting that the
stubs_sources directory for the public API did not exist.
With this change the build succeeded.
Checked the contents of the resulting .srcjar files and made
sure that the public one was empty and the others contained
the SdkExtensions.java class and a package-info.java file.
Change-Id: Ia468a3f37349f2dbc21db67744bda6461498d515
This reverts commit 7f97957ded.
Reason for revert: breaks sdk snapshots b/173508731
Bug: 173508731
Test: Ran prebuilts/runtime/update.py and then m nothing
Before revert it failed
After revert it worked
Change-Id: I9c081681fac589e37788a0d592435e3224011c58
* changes:
Store ndkKnownLibs in the config
Register the kythe singleton on the Context instead of globally
Store ninja file deps from PackageVarContext in the config
Store SingletonMakeVarsProviders in the config
Asked about error message including "against private API.Adjust
sdk_version", which is a bit hard to parse due to missing space. Also
tried to make error message less verbose, so that it is more clear what
to do, and fixed a grammar mistake.
Bug: N/A
Test: N/A
Change-Id: Ib9a30d86b5cb0e9b3b7d5576ecb9498a9b316042
In preparation for more complicated sandboxing support in sbox, use
a single implementation of the sbox sandboxing by moving genrule to
use RuleBuilder's sbox support instead of creating an sbox rule
directly.
Also move genrule's input list hash support into RuleBuilder.
Test: genrule_test.go
Test: rule_builder_test.go
Change-Id: I292184d02743c7e6887ebbcd232ba565db2ab0cc
Storing ndkKnownLibs prevents multiple tests from running in parallel
as one may be writing to the list while another is reading from it.
Store it in the config so each test has its own copy.
Test: go test -race ./apex
Change-Id: Iba57c9494012c9e0ae9e5ffaa63b9b2bd2c77492
Store SingletonMakeVarsProviders in the config instead of a global
variable to avoid races between tests running in parallel.
Test: all soong tests
Change-Id: I2ab64f368b5ac673fd985399d4421ed018abc562
This change allows a test (native, java, rust or python) to be included
in host-unit-tests suite when test option `unit_test` is set to true.
Bug: 172006742
Test: m host-unit-tests
Change-Id: I69d3eb5b51198c549e2e6914ceac3a4fc33c3cf2
When adding a subcontext in a class loader context tree, there are two
possible cases: 1) the root of the subcontext is itself a <uses-library>
and should be present as a node in the tree, or 2) the root is not a
<uses-library>, but some of its dependencies are -- in that case they
should be disconnected from the root, and the resulting forrest should
be added at the top-level.
Example:
1) C is a <uses-library>:
A
├── B
└── C
├── D
└── E
└── F
2) C is not a <uses-library>:
A
├── B
├── D
└── E
└── F
Before the patch subcontexts for transitive dependencies were added
before the subcontext for the direct dependency (even if it was a
<uses-library>, resulting in case-2 hierarchy when case-1 should have
been used. Previosuly this didn't matter because class loader context
was a flat set of libraries, but now it matters because class loader
context is a tree.
This patch changes the order in which libraries are added, so that
direct dependencies are added before transitive ones. The context adding
method now accepts an "implicit root" parameter, so that when adding
transitive dependencies it can check if the corresponding direct
dependency is a <uses-library> and already present in the context.
Partially constructed class loader context is now propagated top-down
into aapt.buildActions, so that the method can use existing part of the
context to decide where the missing part should be connected.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I649aff9e27494306885a4f4fc90226c399636b57
The android.WriteFile rule takes careful escaping to produce the
right contents. Wrap it in an android.WriteFileRule that handles
the escaping.
Test: compare all android.WriteFile outputs
Change-Id: If71a5843af47a37ca61714e1a1ebb32d08536c31
Soong currently assumes that installed files should depend on
installed files of all transitive dependencies, which results
in extra installed file dependencies through genrules, static
libs, etc.
Annotate dependency tags for dependencies for which the
installed files are necessary such as shared libraries
and JNI libraries.
This avoids extra installed files, and is also a first step
towards genrules using their own copy of tools instead of
the installed copy.
Bug: 124313442
Test: m checkbuild
Test: java.TestBinary
Test: cc.TestInstallSharedLibs
Test: deptag_test.go
Change-Id: Ic22603a5c0718b5a21686672a7471f952b4d1017
Prepare for using Config when adding singletons by passing
Config to NewTestContext and NewContext instead of to ctx.Register.
This will enable a followup change to store SingletonMakeVarsProviders
registered on the Context in the Config, which is necessary to run
multiple tests in parallel without data races.
Test: all soong tests
Change-Id: Id229629a4e42ff4487d317241673837726c075fc
The switch to use dex jars instead of class jars means that a boot jar
that is defined by a dex_import module will now be checked against the
package_allowed_list.txt so it is possible that it will detect
previously unreported problems.
Test: m check-boot-jars - for failing and passing cases
Bug: 171479578
Bug: 125517186
Change-Id: Ie614898dade0fb43c9418d7afb9138169db6f097
The droidstubs support in sdk/module_exports was a temporary measure
to work around the fact that some APIs were being defined by direct use
of droidstubs instead of java_sdk_library.
This change removes that support as those APIs have all been switched
from droidstubs to use java_sdk_library so droidstubs support is no
longer needed.
Bug: 168301990
Test: m nothing
Change-Id: I3517bed29b030438a0423a6cb8c248992a988222
Some java_sdk_library modules do not have any stubs for some API
scopes. That results in an empty ".srcjar" being created for them which
ends up not creating a directory for the stubs sources when that
snapshot is unzipped. Previously, that would cause a build failure as
the generated java_sdk_library_import module used the directory, which
did not exist, in its stub_srcs property.
This change switches the stubs_srcs property to use a glob pattern of
"**/*.java" relative to the directory instead of using the directory
directly. When the directory does not exist the glob pattern is
resolved to an empty set of paths and does not break the build.
Bug: 172811712
Test: Add sdkextensions-sdk sdk module (local patch)
m sdk-extensions (local patch)
unpack generated snapshot
m nothing - results in build failure due to missing directory
Make this change and repeat above except this time the build works.
Change-Id: I691ffbfdc01ba89bbcaf647dcbb7dfebc3c8aec2
The old representation consisted of a list of libraries (UsesLibraries),
a list of optional libraries (OptionalUsesLibraries) and a mapping from
library name to its build/install paths (LibraryPaths). The separation
into lists and map was necessary because of special handling of
compatibility libraries, which is now unified with normal libraries.
The new representation is a mapping from target SDK version to a tree
structure ClassLoaderContext. Each node of the tree represents a library
and contains library name, build/install paths and a slice of
subcontexts for dependencies. The same library may occur in the tree
multiple times in case it is a dependency of multiple libraries. The
order in which libraries are added matters (the resulting tree shape may
be different).
Test results have to be updated, as the resulting <uses-library> list is
reodered (previously it was a sorted list of map keys, and now it is
formed by a depth-first preorder traversal of the class loader tree).
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Bug: 168686456
Change-Id: I11be8cd2967f004fd58753d7c5fb99fed179cd63
--patch-module lookup.
javac --patch-module accepts a list of directories and/or jars for JDK9
module patching (see bug for more details). In Bazel-Ninja execution,
Bazel executes the javac action in its own execution root working
directory, unlike Ninja, which works in the Android top level directory.
The Bazel execution root is formed of a symlink forest of top level
directories. This symlink forest is a problem for javac because it
doesn't traverse into symlinks.
To support Bazel executing these javac actions, we explicitly encode the
module directory, and the top level directory of any other source file
inputs into the --patch-module javac flag.
For example, the "core-all" libcore module compiles into `java.base`,
and depends on filegroups outside of `libcore` (`tools`). This CL adds
`tools` to the --patch-module lookup dir, on top of `libcore`.
See java_test.go for more details.
Bug: 150878007
Fixes: 150878007
Test: m
Test: bazel build droid (aosp_flame)
Change-Id: Id95b0a9a675fc75678f7b5e600344b4403f0c518
