Invokes hiddenAPIExtractInformation() on the dex jar provided by the
deapexer (on behalf of prebuilt_apex) so that hiddenAPI can extract the
information it needs, if anything, from the dex file (and accompanying
classes implementation file).
The dex file provided by deapexer has already had the hiddenapi
information encoded into it so it does not need to do that again.
This change adds the primary parameter to hiddenAPIExtractInformation()
and checks it (and also the hiddenAPI.active property) before it does
anything. That ensures that it behaves correctly when called directly
as well as when called from hiddenAPIExtractAndEncode().
Bug: 178361284
Test: m droid
Verified that hiddenapi files (both aggregated ones and for the
individual modules) are not affected by this change.
Also verified that the hiddenapi files created when using the
prebuilts (using SOONG_CONFIG_art_module_source_build=false) are
the same as when using the source. There is a slight difference
in the order but otherwise identical.
Change-Id: I7abb63fd310bb94787ab7f4821e5fd283dc03046
A follow up change needs to be able to contribute to the information
the hiddenapi process collates without having a dex file encoded. This
change pushes all the functionality related to information gathering
into the hiddenAPIGenerateCSV() method and then renames it and the
hiddenAPI() method to make it clearer what they do.
Bug: 178361284
Test: m droid
Verified that hiddenapi files (both aggregated ones and for the
individual modules) are not affected by this change.
Change-Id: I04417720216a0fbadcd88e6185e7de6570af6216
Previously, the hiddenapi() method combined both checks to determine
whether a module contributed to/was modified by the hiddenapi process
and logic to create ninja rules to perform those tasks. This change
separates the former out into a new initHiddenAPI() method.
The main purpose of this is to simplify the process of allowing the
CSV generation to be separated from the encoding. That is required
because when a java_import retrieves its dex file from the apex it
has already been encoded.
The initHiddenAPI() method is only called for java.Library (and
indirectly for java.SdkLibrary) and java.Import modules which means
that the hiddenapi() method does nothing for any other module type.
That is consistent with the previous behaviour because while the
hiddenapi() method is called for other module types they fail because
the boot image jars only support java_library, java_sdk_library,
and java_import at the moment. While it will need to support
java_sdk_library_import once any of the libraries that are currently
provided as java_sdk_library modules switches to providing prebuilts
that is outside the scope of this work.
Bug: 178361284
Test: m droid
Verified that hiddenapi files (both aggregated ones and for the
individual modules) are not affected by this change.
Change-Id: Iaa91e0a8e2bffec03296dd894e9662556f4464c0
Jarjar doesn't exit with a nonzero return code when there is a syntax
error in a rules file and doesn't write the output file. Without a
nonzero return code ninja prints a warning but continues, which leads
to stale results on incremental builds where the output file already
exists, or delayed errors on clean builds whre the output file didn't
exist.
Delete the output file before running jarjar, and then check if it
exists after running jarjar.
Fixes: 119516143
Test: m out/target/common/obj/APPS/TeleService_intermediates/classes.jar
Change-Id: I7e9f7ff34de565a986ab0dc6e375f606c91c3846
Prevents the hiddenapi files index and metadata files from including
duplicate entries.
Bug: 178361284
Test: m droid
Compared hiddenapi files before and after change
Verified that the only differences were due to the removal of duplicates
Used sort -u to remove duplicates from before file and compared with after file
Change-Id: I0b9e420aec42cdcf4584099a7ffd2ed9c3715d6d
The index file and the metadata file both currently include duplicate
entries due to them including both the <x> and <x>.impl libraries
created by java_sdk_library in their inputs, plus including both source
and prebuilt versions of the same named module. This change adds a test
to illustrate that behavior. A follow up change will correct the problem
and update the test accordingly.
This change only adds a test for the index file because the metadata
file depends on files from frameworks/base which makes it difficult to
test. Bug 177317659 will fix that and allow the metadata file
generation to be tested too.
Bug: 178361284
Test: m nothing
Change-Id: I33921d7267c9f4bb42726343d73f8a396d536aaa
By enabling an android_app_import module to supply the
special framework-res module, it becomes possible to
create a split build that excludes the source of over
10,000 files under frameworks/base/core/res, replacing
this source with a prebuilt. However, since other parts
of a monolithic build use the source of framework-res,
this scheme works only if your split build manifest
excludes modules that depend on framework-res source.
Bug: 176851898
Test: lunch aosp_arm64-userdebug && m nothing
Test: new TestAndroidAppImportExportPackageResources
Test: local build without prebuilt framework-res
Test: local build with prebuilt framework-res
Change-Id: If00d9dbc656c8406c038448d09f93f767c1e06d1
Hiddenapi processing currently requires access to the class
implementation jars for libraries on the bootclasspath which means that
they need to be provided as part of the prebuilts. This change modifies
the java_boot_libs property on the sdk to make those files available.
Modularization of the hiddenapi processing will hopefully remove the
need for these to be exported so this should be temporary.
Bug: 178361284
Test: m art-module-sdk
check generated snapshot zip contains implementation jars
Change-Id: I9e94662dddb0ddb85a477ae6d27e533085147e88
Previously, it ignored any module that was not a platform apex variant
however that required every module that was referenced from the boot
jars to have a platform variant which is not the case when building
from prebuilts.
This change switches it to explicitly check that the variant is for
either the appropriate apex or the platform depending on what is
configured in the BootJars or UpdatableBootJars.
It partially duplicates some logic from the getBootImageJar() function.
It intentionally does not refactor the getBootImageJar() to allow for
reuse because coupling the hiddenapi and dexpreopt logic would make
refactoring either of them more difficult. Any duplicated code will be
deduped once they have both been refactored.
Bug: 178361284
Test: m droid
Change-Id: I4b4e0dc8ee40c1ba1713d7ef72df13d175e84af6
This currently expands all globs, still need to support converting glob
syntax.
Test: go build_conversion_test
Test: GENERATE_BAZEL_FILES=true m nothing
Test: m nothing
Bug: 165114590
Change-Id: If7b26e8e663d17566fad9614ca87a8da1f095284
This allows java_test_host to have arch-specific data files. Currently,
VirtualizationHostTestCases needs this to have arch-specific kernels as
its data.
Bug: N/A
Test: m VirtualizationHostTestCases
Change-Id: Ib5680ef48b613955ad92c9bc212184ac75900d3e
A path to an nonexistent file caused dex2oat to write an empty path in
the class loader context stored inside of the OAT/ODEX file, which
resulted in class loader context mistmatch and a failure to load
dexpreopt code on device.
An example of a faulty class loader context for GoogleDialer, can be
seen either with oatdump or by grepping logcat for class loader context
mimatch messages (the first empty PCL[] is expected, note the second
empty PCL[] in the subcontext for shared libraries):
PCL[]{PCL[]#PCL[/system/framework/org.apache.http.legacy.jar*22205474]
This CL removes the nonexistent path from the generated dexpreopt.config
file, which works in conjunction with a change in makefiles that stops
using the removed config field. This is possible because makefiles can
access DEX files using a module name and "intermediates-dir-for" macro.
Bug: 132357300
Test: lunch cf_x86_64_phone-userdebug && m && launch_cvd \
adb wait-for-device && adb root && adb logcat \
| grep -E 'ClassLoaderContext [a-z ]+ mismatch'
# empty grep output, no errors
Change-Id: I8d16f77c6f76ad6234cc4114ad3545cbe572ef13
Previously, ConfiguredJarList would accept an empty apex name,
e.g. ":jar" which makes no sense as every apex has to have a non-empty
name. This change makes an empty apex invalid.
In order to improve the test coverage of the TestConfiguredJarList test
this change also changes the implementation of
CreateTestConfiguredJarList([]string) to marshal the supplied strings
into a json list and then unmarshal into a ConfiguredJarList which more
closely matches how it is used at runtime.
Bug: 178361284
Test: m nothing
Change-Id: I7dfec6b4cc1923aa99746e976da0393922ef0791
In order to allow the hiddenapi code which expects its inputs to be
ModuleOutPath to consume the output from the deapexer module type (used
by prebuilt_apex) this change converts the hiddenapi from using
ModuleOutPath to use OutputPath instead.
This is part of a general cleanup to remove ModuleOutPath that is
separated out in order to avoid having the hiddenapi work dependent
upon and possibly delayed by issues with that general cleanup.
Bug: 178361284
Bug: 179124768
Test: m droid
Change-Id: I890f775bf5e33528dbaa62b95fa4198185ff8bf8
Mistakenly used HostAndDeviceDefault (which builds host and device
variants by default) instead of HostAndDeviceSupported which only
builds a device variant by default.
Moved the test definitions of art and framework boot images from being
defined in all Java related tests into the test where they belong. This
is needed in order to improve the ART and framework boot image specific
testing.
Bug: 177892522
Test: m droid
Change-Id: I16771f09bd789033e18c58ae6dd4b6b9e865d831
Previously, the apex module had to hard code behavior specific to the
art apex module in order to include the art boot image. This change
adds support to the apex module to allow the boot images to be
specified per apex.
In combination with a change to add the "art-boot-image" to the ART
apex this allows the custom code for handling the art boot image in
apex to be removed.
That custom apex code also included the logic to ensure that the
GlobalSoongConfig was initialized for use by the dex_bootjars
singleton. That logic has been moved from the APEX to the boot_image
module. That ensures that it will be run if and only if a boot_image
module is present in the checked out repos. So, limited manifest
checkouts which do not contain the art or frameworks/base repos (which
is where the boot_image modules are defined) will not attempt to run
this logic, which would fail because dex2oat would not be present.
Bug: 177892522
Test: m droid
Change-Id: I02d25fbef6e864e31eb5e0f4eb50358c79486db0
The documentation was unclear because there are at least three
different ways (codename, version, API level) to refer to each
version, see https://source.android.com/setup/start/build-numbers
It is further complicated by the fact that this value is taken
as a String even though the API level it refers to is normally
an integer. To disambiguate, this CL adds an example.
Test: Treehugger only.
Change-Id: I40c13104a87d16c84c2098f36f7f63447d3dda4d
are present.
1) The boot jar to APEX mapping is maintained by the base names for
both of them. When building with prebuilt modules and APEXes, that
means we need to take care to compare them without regard to any
"prebuilt_" prefixes.
2) VisitAllModules can visit disabled modules and both source and
prebuilt modules, so they need some conditions to skip modules that
aren't applicable for boot jars.
Test: `m droid`
Test: `m droid SOONG_CONFIG_art_module_source_build=false`
with fresh ART Module prebuilts in place
Bug: 171061220
Change-Id: Iced269d29127bc8b8f9b3171adb60a97d115628b
This is needed for Java libraries that are <uses-library> dependencies
of Java libraries and apps defined as Make modules. Each dexpreopted
module in Make generates a dexpreopt.config file, which incorporates
information from its dependencies' dexpreopt.config files. For
dependencies that are Make modules their dexpreopt.config files are
generated by Make, and for Soong modules they are generated by Soong.
Since Soong doesn't know which libraries are used by Make, it generates
build rules for a superset of the necessary libraries.
Bug: 132357300
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: I325b1037658736ee3c02450b08c00eca1a175962
Incompatibilities are a bit special in that we only ever want to use
the "latest" if it is for a non-finalized SDK.
Add a new argument, next_api_dir, and use only those files to create
"latest incompatibilities". Create empty incompatibilities for all
modules not in next_api_dir.
Bug: 178171189
Test: m
Change-Id: I727a52e3a45a5e607c6176d481b40fbf495c6eb0
Adds a boot_image module type. Follow on changes will add instances of
boot_image to represent the ART and framework boot images in the art
and frameworks/base repositories respectively.
For the moment they retrieve their associated boot image configuration
from the map returned by genBootImageConfigs() and leave the actual
work of creating the ninja rules to create the boot images to the
dex_bootjars singleton.
Bug: 177892522
Test: m droid
Change-Id: Ib69701de0d24d996bb8e8be7a20b941be907390e
The main difference between a singleton and a singleton module that
affects this change is that the latter requires a module to be defined
in order for the singleton to be instantiated. This change defines the
module in both the tests and the standard build.
Bug: 177892522
Test: m droid
Change-Id: Id6669835cf3a2ab7359fa53047eb9042992a9362
Previously, the createGlobalSoongConfig() function was explicitly
prevented from being used in tests because it would fail. However, it
turns out that is no longer the case and it does now work.
That allows the following changes to be made:
* Tests no longer need to use GlobalSoongConfigForTests() to
prepopulate the cache.
* GlobalSoongConfigForTests() is only needed in the dexpreopt
package.
Bug: 177892522
Test: m nothing
Change-Id: Ifcbb1a44254c5d2d10c1d02ab23227488d1d1ed1
Insulate tests that exercise code in the java package from having to
register the build components provided by the java package by providing
a single function that registers them all. This follows the pattern
currently used in the cc and rust packages.
This change is in preparation for switching the dex_bootjars singleton
from a singleton, which does not require a module definition in order
to be instantiated, to a singleton module which does. That will require
adding a module definition into java.GatherRequiredDepsForTest() and
this change ensures that the required components will have been
registered in every test.
Bug: 177892522
Test: m nothing
Change-Id: I6475db8240894947dd07c89a940a3e4f201aa598
Add some instructions for what to do.
Bug: 177806245
Test: m nothing (with java_sdk_library with no tracking files)
Change-Id: I286018f4d9105d5ade1e76cddb8670d0d097d77d
Bug: 176171716
Test: build_mainline_modules.sh and ensure that the ART boot image is
built: `find out -type f -name '*.art'` is nonempty for every arch.
Change-Id: Ibc45581eef2b205c750a30709780cf659ba7cfa1
Without LOCAL_SOONG_DEX_JAR, ninja fails with a missing
dependency error.
Test: m nothing
Test: new TestImportSoongDexJar
Bug: 173705556
Change-Id: I54a4c6ea93877667a3fb97f8b2621c42e431f577
With the addition of the compile_dex property to the
java_import module it becomes possible to include a
java_import module in an apex. This change allows the
dependency and adds a test.
Bug: 177228901
Test: m nothing
Test: new TestApexWithJavaImport
Change-Id: I9336dade1857109e2fd21f7d57e1dc4abc4a402c
By enabling these hiddenapi CSV files to be prebuilt, it
becomes possible to create a split build that supports
the hiddenapi encode dex step, but doesn't contain all
of the java sources needed to generate the CSV files.
Bug: 175048716
Test: m nothing
Test: new TestHiddenAPISingletonWithPrebuiltCsvFile
Test: local build without prebuilt hiddenapi
Test: local build with prebuilt hiddenapi
Change-Id: I805ea3ec05860d2df211a3985ec025bf36f0d775
Dexpreopt and boot jars package check all require access to dex
implementation jars created for java_library and java_sdk_library. They
were available when building from source but not when building from
prebuilts, even though they are embedded within the .apex files that
are referenced from prebuilt_apex.
This changes adds support to prebuilt_apex to export the dex
implementation jars and updates java_import to use those exported dex
implementation jars.
In a source build dexpreopt/boot jars package check access the apex (or
platform) specific variant of a java_library, e.g. core-oj, from which
it retrieves the dex implementation jar path.
After this change in a prebuilt build dexpreopt/boot jars package check
behave in the same way except in this case they retrieve the dex
implementation jar path from the apex (or platform) specific variant of
the java_import, e.g. core-oj.
The work to export files from a `.apex` file for use by other modules
is performed by a new `deapexer` module type. It is not used directly
in an `Android.bp` file but instead is created implicitly by
`prebuilt_apex`,
In order to do that this contains the following changes:
* Adds a new `dexapexer` module type to handle the exporting of files
from the `.apex` file.
* Adds an exported_java_libs property to prebuilt_apex to specify the
set of libraries whose dex implementation jars need exporting.
* Creates apex specific variants of the libraries listed in the
exported_java_libs property.
* Adds the set of exported files to the ApexInfo to make them available
to the apex specific variants.
* Prevents the prebuilt_apex variants from being merged together as
they will not be compatible.
* Modifies java_import to use the exported file for variants of a
prebuilt_apex.
* Adds a ninja rule to unpack (using deapexer) the contents of the
prebuilt_apex's apex file, verify that the required files are present
and make them available as outputs for other rules to use.
* Some minor refactorings to support these changes.
* Adds tests to cover prebuilt only, prebuilt with source preferred,
and prebuilt preferred with source.
Test: m nothing
Bug: 171061220
Change-Id: Ic9bed81fb65b92f0d59f64c0bce168a9ed44cfac
The build has some implicit dependencies (via the boot jars
configuration) on a number of modules, e.g. core-oj, apache-xml, that
are part of the java boot class path and which are provided by mainline
modules (e.g. art, conscrypt, runtime-i18n) but which are not otherwise
used outside those mainline modules.
As they are not needed outside the mainline modules adding them to
the sdk/module-exports as either java_libs, or java_header_libs would
end up exporting more information than was strictly necessary. This
change adds the java_boot_libs property to allow those modules to be
exported as part of the sdk/module_exports without exposing any
unnecessary information.
Some points to note:
* The java_import has to have a valid file for the src property
otherwise it will be disabled.
* The src property is supposed to reference a jar file but the
java_boot_libs property will make it reference an empty file (not
an empty jar) so that any attempt to use that file as a jar, e.g.
compiling against it, will cause a build failure.
* The name of the file passed to the src property should make it
clear that the file is not intended to be used.
* The test makes sure that only the jar file is copied to the
snapshot.
Test: m nothing
Bug: 171061220
Change-Id: I175331e4c8e3874ab70a67cdc2f76ed1576e41eb
TestJavaSdkLibraryEnforce is too slow because it tests all
combinations of options. Change TestJavaSdkLibraryEnforce to
run test on specific test cases, not all combinations.
Bug: 177323052
Test: go test -timeout 10s -run ^TestJavaSdkLibraryEnforce$ android/soong/java
Change-Id: Ie7fe4e22b570a3e25259a6ad4bd37936805c6604
These APIs were temporarily blocked but are now being moved to the
max-sdk-r for final release. Tag these APIs as "lo-prio" since we
believe that they are unused.
Bug: 173499988
Test: m
Change-Id: If9c6be963faa75df77cf3cc7761b384324c8cd3e
* changes:
Revert^2 "Define the standard license_kind rules."
Revert^2 "Export soong license data to make."
Revert^2 "Add ability to declare licenses in soong."
* changes:
Revert "Add ability to declare licenses in soong."
Revert "Export soong license data to make."
Revert "Define the standard license_kind rules."
Revert submission 1377717-metalics
Reason for revert: This has broken renderscript_mac target for aosp-master, see b/176909442
Reverted Changes:
I26ac54ca9:Define the standard license_kind rules.
I656486070:Export soong license data to make.
If9d661dfc:Export soong license data to make.
I97943de53:Add ability to declare licenses in soong.
Icaff40171:Rough-in license metadata support to make.
Ib8e538bd0:Add variables for notice deps, license kinds etc.
Change-Id: I51799c94a274eadab414abd80a07b5cda4584be9
The removed API has been unused since https://r.android.com/1533342
(except for unit tests).
Changes in the unit tests reflect the change of API in
https://r.android.com/1533342: early errors caused by unknown library
paths at CLC construction time have been replaced with late errors at
the time of CLC validation.
Bug: 132357300
Test: m nothing
Change-Id: I739c7c41b6f882b7e28cdd6acd05961d754d8687
The property can be used to pass additional flags to the AIDL compiler.
For example,
cc_library {
..
srcs: ["Foo.aidl"],
aidl: {
flags: [
"-Werror", // warnings as error
"-Weverything", // turn on all warnings
],
},
}
Bug: 168028537
Test: soong test
Change-Id: I8120eeae7cd7b1acdd34c554af996a29e760a368
This flag was only used by sdk_library.go, and is no longer needed
since sdk_library.go now knows which libraries are missing latest_api
tracking files.
Bug: 176092454
Test: m
Change-Id: I5a967f784bde99f103b85654c794e8d7110fd0db
Metalava used this attribute to potentially re-write some nullness
annotations from @Nullable to @RecentlyNonNull, and not doing so can
cause problems when compiling kotlin.
Bug: 176092452
Test: m art.module.public.api.stubs && \
rm -rf /tmp/lib && \
unzip -qd /tmp/lib art.module.public.api.stubs.jar && \
javap -v /tmp/lib/java/util/concurrent/ConcurrentHashMap.class | \
grep Recently
Change-Id: I9012798f27e39d9a53dbcf0976548f6cec2d3150
IntelliJ's indexer is unhappy with the full paths in the proto
and aidl srcjars. Use the -srcjar argument to soong_zip, which
causes it to extract the correct filename for .java files based on
the package statement in the file.
Bug: 176209347
Test: manual
Change-Id: I63d9d4f6ba670e3b851835d719519d675ae54c7f
Setting uncompress_dex for java_import in the same way
as java_library enables using a java_import as an art
jar or a boot jar.
Bug: 175619567
Test: m nothing
Test: TestHiddenAPISingletonWithPrebuilt
Change-Id: I0b552a11d1630a014cf978520ccc5977fdf74066
Previously CLC construction was scattered across different module types
and dependency tags. This CL moves all logic to one function, which
handles all special cases. This will allow to simplify CLC API and
reduce the number of different ways in which CLC is constructed.
Previously some of the cases failed early (at the time when a library is
added to CLC) if the build/install paths were unknown. Other cases did
not fail early, but were validated later before CLC was used. Late
failures are necessary because some of the libraries with unknown paths
still have to be processed by manifest_fixer (which doesn't need library
paths), but they do not use dexpreopt (which needs library paths). This
CL removes the early failures (all paths are still validated later).
The CLC tests do not fail because they use a private method that toggles
the "strict" flag (that enforces early/late failure mode) manually in
the method call.
The CL also makes a functional change in the way CLC is constructed for
component libraries that have an OptionalImplicitSdkLibrary(), or
libraries that are disguised as SDK libraries via `provides_uses_lib`.
Previously such a component/disguised library X was added to its own CLC
as a sibling element of X's own <uses-library> dependencies, which
created incorrect CLC structure. Now this is handled by addCLCFromDep,
when X is processed as dependency and added as a top-level CLC element
with its sub-CLC properly nested under it.
Bug: 132357300
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: I6a512209b87b81d785875f10f76b21c81b2ed579
Setting this to true by default is dangerous as it can mask bugs. Create
a dedicated attribute for java_sdk_library to enable this behavior
instead. The default will be flipped in a future CL when all the current
offenders have been fixed.
Fix all the tests to have the right API files.
Bug: 176092454
Test: m nothing
Change-Id: Ieab94bcb74abf8d018365a56fb447fe3dbd46957
dexpreopt doesn't strip dex files from the input jar anymore, so there's
no point returning the input jar path untouched.
Test: m nothing + TreeHugger
Change-Id: I8fde6cdc19e85a2fbc946513696417b945c5de0f
This method logically belongs with other UsesLibraryDependency methods,
as it is used in the same context when computing class loader context.
Previously it was part of Dependency interface, which doesn't cover SDK
libraries. We do not currently have the necessary information for
SdkLibraryImport (so ClassLoaderContexts() returns nil for it), but we
do have it for SdkLibrary (via Library).
Bug: 132357300
Test: m nothing
Change-Id: I56437f260efc6a9af3f45b334e84e915244ccce1
We had a dependency on each file in the asset directories, but that
wouldn't cause aapt2 to run if a file was removed. Add a dependency
on a file that contains the list of files in the asset directories.
Fixes: 172867096
Test: m CarrierConfig && rm packages/apps/CarrierConfig/assets/carrier_config_no_sim.xml && m CarrierConfig
Change-Id: I35f3b85355fa890a3e95eaa6458a21466b6930e4
This fix a bug in a recent android_app_import-related change
(I8215aa1a6dad74b503eaa1169a64f8c30dda287c) where it uses an incorrect
module reference, and so disables a prebuilt module if its source-based
counterpart is disabled.
Test: app_test.go
Bug: 152343232
Change-Id: Ic7f5ca40be58f06e44b5ec4945caf209ef2dae96
I added in case anyone needs to access AndroidMkEntries to generate
footer lines, but nobody uses it, and it only confuses people.
Test: m nothing, TreeHugger
Change-Id: Ic8a450e3c306d9228c1fdec212c7441bd6aaee03
Previously, only the <jar> part of the boot image configuration pair of
<apex>:<jar> was used to select the module that provides the boot image
dex. The name was sufficient to select the module but not the module
variant and it relied on the platform variant not being installed to
select a unique variant. Unfortunately, when modules are provided as
prebuilts they are not installed and so they get ignored.
This change removes the install check and instead checks the <apex> as
well to select a unique variant.
It also moves the DexJarBuildPath() and ApexModule checks to after
checking the name and treats them as errors. It is safe to do so
because every module that has the same name has to have the same module
type and in order for the module to be valid in the boot image
configuration it must pass those two checks. Treating these as errors
rather than silently ignoring them makes it easier to diagnose problems
with the configuration and/or the boot image modules.
Test: m droid
Bug: 171061220
Change-Id: Ie51f097e081907ea5b75d75840736b10d8d883e8
This change does not break modules like "core-oj" that are in multiple
apexes, i.e. com.android.art, com.android.art.debug and
com.android.art.testing because they all shared the same variant. So,
the getBootImageJar() is only called once for that variant.
Test: m droid
Bug: 171061220
Change-Id: Ibf26da147af2b49ab9e4588030e8cd4002d04a7a
This fixes a bug where android_app_import or android_test_import without
a matching variant or a default apk property value breaks the build.
Test: app_test.go
Fixes: 152343232
Change-Id: I8215aa1a6dad74b503eaa1169a64f8c30dda287c
Adds some additional information into the paths that are created when
modules are missing in Soong but SOONG_ALLOW_MISSING_DEPENDENCIES=true.
Test: try and build platform against art prebuilts
Bug: 171061220
Change-Id: Ifbcc0af5bdbd15409758a3b6f216cf9b3b5dba31
If some Java library/app depends on an SDK component library (e.g. stubs
library), then it transitively depends on the SDK library itself
(because the component library has a dependency on its SDK library).
Previously having this transitive dependency resulted in adding the SDK
library to the <uses-library> dependencies of the library/app. However,
this doesn't make sense if the app has a *static* dependency on the
component library. This patch stops adding <uses-library> dependency in
that case.
Bug: 132357300
Test: m nothing
Test: added new Soong test that would previously fail with an error:
invalid build path for <uses-library> "fred"
Change-Id: I697a65e461037c95ec56b6c321afa4ec52ccbbec
Enable the RuleBuilder and RuleBuilderCommand methods to access
the BuilderContext by passing it to NewRuleBuilder instead of
RuleBuilder.Build.
Test: genrule_test.go
Test: rule_builder_test.go
Test: m checkbuild
Change-Id: I63e6597e19167393876dc2259d6f521363b7dabc
MTS is introducing partial MTS test suites that are per-module, with
names of the format: mts-${MODULE}. By centralizing the code for test
suites, we can automatically add "mts" test suite when an
"mts-${MODULE}" test suite is specified, reducing duplication.
Test: m mts
Bug: 170318013
Change-Id: I8ce9d3c252fcc0a937bb5f2826d21cb6c6932d82
Instead of setting DistFiles to use the api stub (if present) as the
default dist file this simply makes OutputFiles(tag) return the api
stub file for the DefaultDistTag.
Test: m nothing
m dist sdk - before and after this change, compare result to
make sure that there are no significant differences.
Bug: 174226317
Change-Id: I39d615c5bf8d20d59db7eeb98d942210ec0aa8ba
This is a temporary measure to allow these APIs to be identified by
downstream tooling. Before S is finished, these APIs will be moved
to the max-target-R list anyway.
Adding the lo-prio flag should have no semantic impact on these APIs
but does allow them to be distinguished from the regular blocklist
APIs.
Test: m
Bug: 174455522
Change-Id: I031dcecbdef34a4f93a0fec1a92d95f769918486
Uses the dists property to copy the removed API specification file for
each API scope alongside the API specification file in the dist.
Bug: 158544979
Test: m nothing
m dist sdk - before and after this change, compare result to
make sure that there are no significant differences other than
the after now contains -removed.txt files for each scope of each
java_sdk_library
Change-Id: If23c594d29a12e49d2c5a8945ad488874bb1590c
A previous change handles dist properties automatically for all module
types and as a result has made the java.Library setting of DistFiles
redundant so this change removes that and the tests that duplicate
tests of the general mechanism.
Test: m nothing
m dist sdk - before and after this change, compare result to
make sure that there are no significant differences.
Bug: 174226317
Change-Id: Ib79a3bdd46897efd84a9c456c37c374bd6036303
Change https://r.android.com/1335521 added tag property to the Dist
struct so that it could be used to select one of a number of different
output files to copy to the dist instead of the single file that the
module type made available for dist. The output files were selected
by passing the tag to OutputFiles(tag).
Module types that wanted to support this new approach had to explicitly
set AndroidMkEntries.DistFiles = GenerateTaggedDistFiles(module).
Unfortunately, doing that had a side effect of changing the behavior of
dist entries without a tag.
That was because the change treated a tag that was not specified, as
being the same as "". So, prior to the change no tag meant use the
default dist file but after it meant use the paths returned by
OutputFiles(""). That changed the behavior of the java.Library type
which affected the behavior of the android_app module type.
Prior to the change the java_library would make the
Library.outputFile available for dist when no tag was specified. After
that change it would make Library.outputFile plus
Library.extraOutputFiles. The latter is usually empty except for
android_app which adds some extra files into there which will now be
copied to the dist. That change may have been intentional but there
was no mention of it in the change or the bug. Even if it wasn't
intentional it may still be beneficial.
Any module type that wants to add support for tags in dist runs the
risk of introducing similar changes in behavior. This change
differentiates between the tag not being set and the tag being set to
"" to avoid that possibility and to make the default behavior
explicit for those module types that have switched.
It does so as follows:
* Adds a DefaultDistTag constant that is used when the tag is not set.
It is a string that is unlikely to be used as an actual tag as it
does not start with a . and uses some special characters.
* The DefaultDistTag is used in MakeDefaultDistFiles(paths) to indicate
that the supplied paths are the default ones and and also in
GenerateTaggedDistFiles() for Dist structures that have no tag
property set.
* The DefaultDistTag is passed to OutputFiles(tag) just in case the
module type has explicitly defined the paths to associate with that
tag in there. If it has then it overrides the legacy behavior. If it
has not then it is just ignored and falls back to using the previous
behavior.
* The java.Library.OutputFiles(tag) method explicitly handles the
DefaultDistTag and returns Library.outputFile for it which restores
the behavior from before the change that added dist.tag support.
* Similar change was made to apexBundle.OutputFiles(tag) in order to
preserve its previous behaviour.
* The customModule used by TestGetDistContributions has been modified
to also preserve its previous behavior after this change.
Test: m nothing
m dist sdk - before and after this change, compare result to
make sure that there are no significant differences.
Test the effect on the apex by following instructions in
http://b/172951145
Bug: 174226317
Change-Id: Ib8f0d9307751cc2ed34e3d9a5538d3c144666f6d
It looks like there is a bug in rewrapper/reproxy that makes it upload the
output file as an input if it still exists in the output tree. This causes
unnecessary cache misses on incremental builds, and can also cause the
action to fail remotely (depending on the service). By removing the output
file at the beginning of the action, we ensure that it can't be uploaded.
Test: ran against a remote execution server; actions no longer fail remotely
Change-Id: Iaac2b23b35d2c876c0244edbfd4a8f159df0563c
It looks like there is a bug in rewrapper/reproxy that makes it upload the
output file as an input if it still exists in the output tree. This causes
unnecessary cache misses on incremental builds, and can also cause the
action to fail remotely (depending on the service). By removing the output
file at the beginning of the action, we ensure that it can't be uploaded.
Test: ran against a remote execution server; actions no longer fail remotely
Change-Id: I98fcc0cf105553a9920b0e96965a438e052d7c05
This patch reworks the approach introduced in
https://r.android.com/1450819. That patch based the decision which
libraries should be added to the manifest <uses-library> tags by the
manifest_fixer on the "shared" status of the library.
That approach is incorrect for two reasons:
- It doesn't make sense to have a non-shared library in class loader
context ("shared" libraries are those specified in
frameworks/base/data/etc/platform.xml, and they are the only ones
that PackageManager knows about).
- It doesn't make sense to add anything but the top-level of the
class loader context tree to the manifest, because this part of the
tree is flattened to a sequence, and PackageManager cannot restore
it to the previous tree shape (there is an information loss).
This patch removes the "shared" bit of information from class loader
context elements and assumes that all libraries that end up in class
loader context are shared. Consequently, only the top-level libraries
should be passed to manifest_fixer.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Bug: 168686456
Change-Id: I902690f0f38f1047fa79cf6ccbe956077eceaab0
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
hilt_android requires seven separate annotation processors, which
is only feasible to support using exported_plugins to avoid having
to list all seven in every module that uses it. Unfortunately they
all set generates_api: true. Turbine is already disabled for modules
that directly use a plugin that sets generates_api: true, because
turbine doesn't run annotation processors. Also add support for
disabling turbine if a module transitively uses a plugin that
generates APIs via exported_plugins.
Bug: 173397767
Test: TestExportedPlugins
Change-Id: If70354a3dd67efb4ce88bc9c934d41ccb6241b28
Unless no_dist: true is specified the java_sdk_library will
automatically copy the stubs jar and the API specification file (but
not the removed API specification file) for each scope to the apistubs/
directory in the dist from which the sub-directories in prebuilts/sdk
are populated. Previously, the name of those artifacts was based on the
name of the module. This change adds the dist_stem property to allow
the name of those artifacts to be specified separately to the module.
The purpose of this is to allow the art.module.public.api,
conscrypt.module.public.api and i18n.module.public.api java_sdk_library
modules to use a different name when copying to the dist,
e.g. conscrypt.module.public.api should use conscrypt.
Additionally, as the artifacts in the dist end up being copied verbatim
to prebuilts/sdk and the prebuilt_apis module uses those names to
create a filegroup referencing the latest released version of the API
and removed API specification files the dist_stem property is also
used in constructing the name of those filegroups.
Bug: 173715943
Test: lunch sdk-eng && m dist sdk
Compare the results of the above before and after the change to
ensure that this change does not affect the contents of the dist.
See the topic's other change in external/conscrypt for testing
the behavior of this new property.
Change-Id: Ie81345021991ff91ca55fec15b02627135293308
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
This allows the presubmit checker to explicitly allow certain changes to
these APIs, rather than special casing tha max-target-o list. This in turn
will allow other APIs to be tagged as lo-prio in future to get the same
treatment.
Test: m out/soong/hiddenapi/hiddenapi-flags.csv
Bug: 172993934
Change-Id: Ic7cc0243b2b018c96d420a3f266c4b3a6958c32f
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
separate function.
This cleans up the internal wiring for a follow-up --patch-module
functionality change.
Bug: 150878007
Test: m
Change-Id: Ie7d9c2b1ad40e055da8a53d632510bef408fc7d2
This dependency is incorrect and shouldn't exist.
It has been removed in https://r.android.com/1467918
Test: m nothing
Bug: 170710203
Bug: 132357300
Change-Id: If3036437e138b552436f135425e6bd15be043678
Adds a singleton that traverses the module variants finding the ones
that are in the list (updatable and non-updatable) of boot jars and
add a ninja rule to ensure that they only contain packages from an
allowed list.
Replaces a hack that ignored any prebuilt boot jars supplied as dex
file with an equivalent one to ensure that they are still ignored.
A follow up change that switches to checking dex jars will allow the
hack to be removed.
The boot jars check can be strict or lax. If strict then all the boot
jars listed in the configuration must be found, otherwise it will only
check the ones it finds. It is strict by default unless
TARGET_BUILD_UNBUNDLED=true or ALLOW_MISSING_DEPENDENCIES=true.
Moves the script and data file from build/make.
Test: m check-boot-jars - for failing and passing cases
SKIP_BOOT_JARS_CHECK=true - no check-boot-jars target created
ALLOW_MISSING_DEPENDENCIES=true - not strict
TARGET_BUILD_UNBUNDLED=true - not strict
verified manually that apart from path differences the same
files (same check sum) were checked in both old make checks and
the new Soong ones
EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m check-boot-jars
Bug: 171479578
Change-Id: I9d81d6650ba64fc0d48d2dab4ba5a3ba8dd03dec
