The updated error message is more descriptive about the incompatibility
between platform_apis and sdk_version. Implemented as per the discussion
in b/204447559#17
Test: In build/soong, run go test ./java
Bug: 204447559
Change-Id: I826f0ce47313b337f1754a1b6bc11ce65c837a41
Native coverage builds create a second variant of APKs and set
PreventInstall on the non-coverage variant. Skip calling
ctx.InstallFile for APKs and in dexpreopt when PreventInstall
is set.
Fixes: 205865567
Test: m EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true CLANG_COVERAGE=true NATIVE_COVERAGE_PATHS="*" NATIVE_COVERAGE_EXCLUDE_PATHS="art bionic/libc device external/compiler-rt external/clang external/llvm external/swiftshader/third_party/llvm-10.0"
Change-Id: I9e38ac737315db12475e8f9bfb3e0e7c0327fc06
The art tests rely on a dependency existing from
out/host/linux-x86/framework/core-oj-hostdex.jar to
out/host/common/obj/JAVA_LIBRARIES/core-oj-hostdex_intermediates/classes.jar,
override LOCAL_SOONG_INSTALLED_MODULE for the hostdex modules so that
soong_java_prebuilt.mk adds the dependency.
Test: art/tools/buildbot-build.sh --host && art/tools/run-libcore-tests.sh '--mode=host' '--variant=X64' --debug
Change-Id: I9412147fc66d5e5f0dae52d522868a37251f781e
* changes:
Revert "Temporarily add method to get java binary tool"
Move java module installation into Soong
Fix ctx.InstallFile calls for java modules
Make HostJavaToolPath use pathForInstall
cc/java modules can have .aidl files as srcs. Pass min_sdk_version to
the aidl compiler so that it can check some features against it.
For example, ParcelableHolder AIDL type is available since 31.
Bug: 205338951
Test: soong test && m
Change-Id: I7ecab913e00c9b6a3ce870dacbe9773d2ddb7e93
Java binaries and cc binaries are in the same directory again, the
separate method can be removed.
Bug: 204136549
Test: m checkbuild
Change-Id: I2e7ca82448aba5c7e54d3c3c376fe14a953ef4af
Move java module installation rules into Soong by overriding
InstallBypassMake. Update the locations that find host java tools
to look in the Make installation directory instead of the Soong
installation directory, which will no longer be used.
Bug: 204136549
Test: m checkbuild
Change-Id: I5af6d764c97e7ddb5ee121fc9830166c25d831b1
Call ctx.InstallFile on the primary install file last so that the
primary install file can depend on the extra install files, and so that
the primary install file can be inferred from the last installed file.
Add missing ctx.InstallFile calls for the dexpreopt and hostdex outputs.
Fix the install subdirectory for modules installing to the testcases
directory.
Bug: 204136549
Test: m checkbuild
Change-Id: I7edd7647be27439d3ca0ecc589ca5e89d4ba8474
Use pathForInstall instead of PathForOutput for HostJavaToolPath
so that it internally produces an InstallPath that can later support
being converted to Make installpath.
Bug: 204136549
Test: m checkbuild
Change-Id: If4f5d3552b27ffe6b9bc709c4a08d9513c49ef7d
Abandon the use of SOONG_COLLECT_CC_DEPS and SOONG_COLLECT_JAVA_DEPS,
soong can generate module_bp_cc_deps.json and module_bp_java_deps.json
without passing any variables.
BUG: 204397180
Test: rm out/soong/module_bp*json
"m nothing" should see both json files were generated.
Change-Id: If30ad5dbabb6709f834134cbc9a513a9bdc9d9de
cc binaries are moving from out/soong/host/linux-x86/bin to
out/host/linux-86/bin first, to be followed by java binaries.
Temporarily add a method that gets the java binary path while
it is different from the cc binary path.
Bug: 204136549
Test: m checkbuild
Change-Id: I04a7e741436da6be68078f23d074870413a5bb5e
We're not sure what formatting is applied to this but it sure
isn't markdown.
Fixes: 204572072
Test: Build and compare docs
Change-Id: Ib023f0cb490a7c7c5605d426ce5e70a7130d5162
Previously, the selection of system modules was duplicated, once for
source and once for prebuilts. This change dedups that by switching the
source code to use the same mechanism as the prebuilts which will ensure
consistent behavior in future.
Bug: 204189791
Test: m nothing
Change-Id: Ia1729017ae332181c95f7b205dab87fb47d43fb8
Renames to core-public-stubs-system-modules so that it is of the format
core-<sdk-kind>-stubs-system-modules.
Bug: 204189791
Test: m nothing
Change-Id: Iac565c940c2ef92be9cc64c0c6b8102a26afe0dd
Initially prebuilt stub sources only supported directories as input, but
support has been added for packaging them up in srcjar as well. However
the build action was not updated accordingly.
Add support to determine if our input is a srcjar, and if so just use
it directly.
Bug: 204978699
Test: m sdk (with prebuilts)
Change-Id: I302cd34ebd55414d35c4f936cd563a4af89b22c6
When building from source the build uses the java system modules for
the public or module APIs as needed. However, previously when building
from prebuilts it would always use the public API. That difference lead
to build failures when building from prebuilts.
This change makes the selection of java system modules when building
from prebuilts consistent with the selection when building from
sources.
As API levels 30 and 31 (which are the only previous releases to
provide system modules) did not provide separate java system modules
for the module-lib API those levels always use the public APIs.
Bug: 204189791
Test: - before applying these change
m TARGET_BUILD_APPS=framework-connectivity
- build fails with compilation error due to missing module APIs
m sdk dist
cp out/dist/system-modules/module-lib/core-for-system-modules.jar prebuilts/sdk/current/module-lib/core-for-system-modules.jar
- apply these changes
m TARGET_BUILD_APPS=framework-connectivity
- build passes as expected
Change-Id: Id113ff014e7892b1009fbcaad89b1ae23a7c3b79
Previously, system modules were only created for the public API scope.
This change creates them for any API scope as long as its directory has
a core-for-system-modules.jar.
It does that by hooking into the existing logic for creating a
java_import for all jars in the API directories and creating a
java_system_modules for every core-for-system-modules.jar file. That
avoids the need for extra path globs.
Test: m droid
m sdk_public_current_system_modules
- works as expected.
m sdk_module-lib_current_system_modules
- fails with missing target as expected.
touch prebuilts/sdk/current/module-lib/core-for-system-modules.jar
m sdk_module-lib_current_system_modules
- fails with invalid jar file as expected.
Bug: 204189791
Change-Id: I27a264941009e03439d5d847dab14a7b4f6f119f
Previously, the fixture preparer for prebuilt_apis would add a
core-for-system-modules.jar file in every API directory even though
currently they only exist in the public API directories.
This change makes the test environment more realistic by only creating
them for the public API. Rather than hard code that into the test code
(which would duplicate the hard coding in the decodeSdkDep func) this
extracts a function that is used by both. That ensures that any changes
to that func will be reflected in both the test and runtime behavior.
Bug: 204189791
Test: m nothing
Change-Id: I346ac9c0dcf407c61de16b6027663a05821bcf62
Previously, there were no tests for this (outside uses in other tests).
This change adds a test that uses the fixture preparers that create a
prebuilt_api in order to make prebuilt APIs available. That ensures
that both the prebuilt_api is working as expected and the preparer
creates a realistic test environment.
Bug: 204189791
Test: m nothing
Change-Id: I57352aa00f7b268e5286be92f177764dd63ba7e8
Previously, the dist only contained a core-for-system-modules.jar for
the public API. This change adds API specific directories containing a
core-for-system-modules.jar file for each of the following APIs:
* public
* module-lib
Bug: 204189791
Test: rm -fr out/dist
m sdk dist
find out/dist -name core-for-system-modules.jar
- outputted the following:
out/dist/core-for-system-modules.jar
out/dist/system-modules/module-lib/core-for-system-modules.jar
out/dist/system-modules/public/core-for-system-modules.jar
Change-Id: Id1845926e2085f70d58e9fc22e9c11cb3d62b919
Previously Soong's install rules have been disabled when embedded
in Make (ctx.Config().KatiEnabled() == true). The primary blocker
for moving installation into Soong has been the `required` proeprty,
which is too vague to be easily handled in Soong. Keeping
installation in Make has resulted in two host bin directories,
the Make-owned directory (e.g. out/host/linux-x86/bin), and the
Soong-owned directory (e.g. out/soong/host/linux-x86/bin). The
lack of knowledge in Soong about the final, Make-owned installation
location makes it hard to support NOTICE files entirely in Soong.
This patch begins to solve this problem by supporting the creation of
the installation rules into Soong, but rather than writing the rules
to the ninja file it writes them to a Makefile and lets Kati convert
them to ninja. This allows Kati to inject extra dependencies to
handle the `required` property.
Converting all modules to create their installation rules in Soong
would be too complex, so only modules that return true from
InstallBypassMake will use the Soong installation rules. This
is currently only set for robolectric tests.
Bug: 204136549
Test: m checkbuild
Change-Id: I28af9fa7fadece8ea1f98f5efd140c823751cae7
* changes:
Use toModule for all "standard" API surfaces
Run TestClasspath test cases with Always_use_prebuilt_sdks=true/false
Refactor TestClasspath to simplify follow up change
Add tests for prebuilts of all API surfaces
For the purposes of this change a standard API surface is one of the
following:
* public
* system
* test
* module-lib
* system-server
Test: m droid
Bug: 204189791
Change-Id: I88ee9709430ca455dd6c7d1523ae22f8c22b0b7e
Previously, the TestClasspath test cases were only run with the default
setting of Always_use_prebuilt_sdks=false. That meant that some of the
code under test that depended on the setting of that variable was not
tested properly.
This change runs the test cases m with Always_use_prebuilt_sdks=true as
well. Those test cases whose behavior depends on the setting of that
variable are split into two separate test cases, each of which only
runs with the appropriate setting of that variable. All other test
cases are run for both settings of the variable.
That revealed a slight issue with the test setup (a missing
prebuilts/sdk/public/core/android.jar file) which broke the
core_current test when run with Always_use_prebuilt_sdks=true which has
also been fixed.
Bug: 204189791
Test: m nothing
Change-Id: If2ea3fde40c7573262e93691af0b5a57e4d54469
Extracts classpathTestCase and extracts the logic for creating the test
into a separate testClasspathTestCases func.
Bug: 204189791
Test: m nothing
Change-Id: I657fbcde23a18f7f5651c174fbf17a9b7b7f1a9a
Previously, the tests only covered checking the sdk dependencies added
when using a prebuilt current (public) and system SDKs, i.e. with
sdk_version set to "current_30" or "system_30". This change adds tests
to cover other APIs, e.g. "test_30", "module_30" and
"system_server_30". It adds tests for "module" and "system-server" up
to API level 32 as following changes will give them different behavior
as API levels less than or equal to 31 do not have a separate
core-for-system-modules.jar file for the module-lib API.
Bug: 204189791
Test: m nothing
Change-Id: I585a88615439a24abf75250114a86113b5f5da57
This change adds a Soong module that stores the paths to the compilation
artifacts of system server jars in a variable, which will then be
consumed by Make to check if the artifacts are installed. When the check
fails, it means that dexpreopting is not working for some system server
jars and needs to be fixed.
Bug: 201371822
Test: m nothing
Test: manual -
1. Add "service-permission" to DEXPREOPT_DISABLED_MODULES (https://cs.android.com/android/platform/superproject/+/master:build/make/core/product_config.mk?q=DEXPREOPT_DISABLED_MODULES)
2. m nothing
3. See the error:
Missing compilation artifacts. Dexpreopting is not working for some system server jars
Offending entries:
system/framework/oat/x86_64/apex@com.android.permission@javalib@service-permission.jar@classes.odex
system/framework/oat/x86_64/apex@com.android.permission@javalib@service-permission.jar@classes.vdex
Change-Id: I4816f19668f1dae180a34adafdbfa448c97aa0db
For testing purpose, we need to add java libraries to bootclasspath and
systemserverclasspath that are not present in PRODUCT_APEX_BOOT_JARS and
PRODUCT_APEX_SYSTEM_SERVER_JARS.
Currently, we can't unconditionally add all the contents to the config
for test APEXs. Until a formal way is introduced, hardcoding the
artifact in the build system like how it's done for
test_framework-sdkextensions.
Bug: 187444679
Test: atest ApexTestCases
Test: atest StagedInstallInternalTest
Change-Id: I1f7b01a57bc9c46163e025de2ab00e671a42b202
- car-frameworks-service-module is added from com.android.car.framework
apex which only exisits in car products.
Bug: 203233647
Bug: 203201931
Test: build, bootup
Change-Id: I5f13b0505c1ac4fd2fd7b6559e080c8a6fb526e0
Merged-In: I5f13b0505c1ac4fd2fd7b6559e080c8a6fb526e0
(cherry picked from commit 6e3ba9ac3b)
`m platformprotos` with a long OUT_DIR can trigger E2BIG errors in
posixspawn, reduce the commands per shard.
Test: OUT_DIR=$PWD/really-long-out-directory m platformprotos
Change-Id: Ifa4594eac7ba0e1091df0ef75e4dfc3ff366939b
The Android SDK has been built with Make up until now, monolithically,
then split up into several sdk-repo zip files for different purposes.
The Mac and Windows SDKs really only need to contain the platform-tools
and build-tools pieces, but due to this monolithic sdk zip, we had to
build the whole SDK first.
This adds an `android_sdk_repo_host` module that can build these
platform-tools and build-tools zips.
Bug: 187222815
Change-Id: I55809e1d7447dd65e22461f921b2b8abb6d5f822
Call InitDefaultableModule in java_genrule factories to allow
the defaults property to be used.
Bug: 202547639
Test: m checkbuild
Change-Id: I3a5960304af3e9babb30d036d63016087000d773
If the android.jar is not found in the module-lib folder, it falls back
to searching it in the system folder and then falls back on the public
folder.
This only brings the functionality, we are not yet using it.
Test: m nothing
Bug: 202023154
Change-Id: I99c9004740c8e51faf53ebc3ba2444e8164215f3
Previously, the signature-patterns.csv file (which was output in an sdk
snapshot) included implementation details, e.g. the names of classes
that are not part of any API, including the hidden API. This change
allows a bootclasspath_fragment module owner to customize the generated
signature patterns file to remove as many implementation details as
possible from the sdk snapshot. That means that implementation only
changes would not require that sdk snapshots be updated in sync with
the corresponding APEX.
Module owners can remove implementation in the following ways:
1) Limit the number of packages that are treated as split packages by
explicitly specifying the split packages in the split_packages
property. A split package is one whose classes are provided by
separate bootclasspath_fragment modules and so the signature
patterns has to include every class in that package provided by a
specific bootclasspath_fragment module, including implementation
classes, instead of just listing the package.
The default is to treat all packages as being split, so if no
split_packages is specified then it defaults to ["*"] which matches
all packages. Assuming that no package was split unless specifically
stated would require that all the modules that had split packages
explicitly list them before this change could be submitted as
without them this change would break the build.
Once all existing modules with split packages have been updated to
include them then the default may be changed.
2) Adding package prefixes for any hierarchy of packages that are
owned solely by that bootclasspath_fragment. This removes the need
to list the packages in that hierarchy, including implementation
specific packages.
Bug: 194063708
Test: atest --host verify_overlaps_test signature_patterns_test
m out/soong/hiddenapi/hiddenapi-flags.csv
- manually change files to cause difference in flags to check
that it detects the differences.
Change-Id: If2f90cfc41b6fff9fa4ac8b9d4973110938b9392
Previous change that was reverted: https://r.android.com/1835222
An additional test was added that revealed a bug in the previous change
which has been fixed here.
Previously, the behavior of the stub_flags and all_flags properties
was different between S and T. In S they contained paths for the
complete set of stub flags and all the encoded flags. However, in T
they contained filtered sets of flags which if used in S would prevent
build checks from detecting possible inconsistencies. Also, a new
signature_patterns property was added in T that is not supported in S.
This change creates separate properties/files for T and reverts the
behavior of the properties/files that were added in S back to how they
behaved in S. The new properties are called filtered_stub_flags and
filtered_flags.
The S and T properties are tagged with the appropriate
supported_build_releases tag to ensure that they are only output when
specifically targeted.
Bug: 197842263
Test: m nothing
Change-Id: I1ce0a3d6623dabf73e32af1a7457b9b444fc3b7c
Variable PRODUCT_UPDATABLE_SYSTEM_SERVER_JARS was renamed to
PRODUCT_APEX_SYSTEM_SERVER_JARS in https://r.android.com/1779472.
Bug: 191127295
Test: m nothing
Change-Id: I0c8ae839cab443c824760b40d30b4374982010f9
Introduce `commonAttributes` & `fillCommonBp2BuildModuleAttrs used in
CreateBazelTargetModule
Adapt `bp2BuildInfo` to use `commonAttrs` instead of `Name`.
And thus also all downstream users of `CreateBazelTargetModule`.
As initial user, the Soong `required` property will be
translated to Bazel's `data`.
Bug: 198146582, 196091467
Test: build_converstion_test.go:TestCommonBp2BuildModuleAttrs
Test: go test
Test: mixed_{libc,droid}.sh
Change-Id: Ib500e40f7e2cb48c459f1ebe3188962fc41ec124
This change removes the field and the code that uses it which is
effectively dead code as it only does something when the list is not
empty and a previous change removed the only code that added a Path to
this list.
Bug: 201753898
Test: m nothing
Change-Id: I67c74ad2a3b115fd3b20b3b416f45b92c749749c
Previously, the behavior of the stub_flags and all_flags properties
was different between S and T. In S they contained paths for the
complete set of stub flags and all the encoded flags. However, in T
they contained filtered sets of flags which if used in S would prevent
build checks from detecting possible inconsistencies. Also, a new
signature_patterns property was added in T that is not supported in S.
This change creates separate properties/files for T and reverts the
behavior of the properties/files that were added in S back to how they
behaved in S. The new properties are called filtered_stub_flags and
filtered_flags.
The S and T properties are tagged with the appropriate
supported_build_releases tag to ensure that they are only output when
specifically targeted.
Bug: 197842263
Test: m nothing
Change-Id: Iec8b9c539796c507245b69c0aed980fde6d8694f
Previously, the permitted package check was designed to only be run
when building checkbuild. Although, that appears to now be broken.
This change uses a Validation dependency to ensure that the package
check is performed whenever the output file of a java_library is built
as part of the build. The package check runs in parallel with any other
rules that depend on the file.
Bug: 201753898
Test: - change the permitted_packages property in
frameworks/base/test-mock so that the package check will fail.
m out/soong/.intermediates/frameworks/base/test-mock/android.test.mock/android_common/package-check.stamp
- as expected the package check failed.
m droid
- as expected the package check did not fail.
# Made these changes then:
m droid
- as expected the package check now failed.
Change-Id: Id38fe280c79e5505ee4555b845c6da2ae6747bc4
Bug: 194150908
Test: m nothing
Test: manual - 1. Patch aosp/1835087.
2. m out/soong/.intermediates/art/build/sdk/art-module-sdk/common_os/snapshot/Android.bp
3. See prebuilt_systemserverclasspath_fragment modules and
systemserverclasspath_fragments in an sdk_snapshot module.
Change-Id: I7876b077b0b4ed190f01dbfa9533de04ea32d524
Similar to java_boot_libs, java_systemserver_libs only provide access
to their dex implementation jar for use by dexpreopting and do not
provide an actual implementation jar.
This is used in the subsequent CL.
Bug: 194150908
Test: m nothing
Change-Id: Ib2e7d5e6c002314a0231f46934a766f4a27e610a
This is for exporting the contents of systemserverclasspath_fragment for
dexpreopting.
Bug: 194150908
Test: manual - 1. Patch aosp/1818020 and aosp/1834534
2. m SOONG_CONFIG_art_module_source_build=false com.android.art
Change-Id: I7d2d2e02869d8a523f7c0efbbff81706672a95c5
This is the prebuilt side of systemserverclasspath_fragment, currently
for used for dexpreopting.
The change to automactially generate
prebuilt_systemserverclasspath_fragment rules will be in a separate CL.
Bug: 194150908
Test: m nothing
Change-Id: Ibf5322f80f78ac3ca037489f4a279456fe38a23f
There are cases where two modules try to install the same test data
into CTS, which results in collisions when CTS puts the data for all
tests in the same directory. Add a flag that allows enabling a
per-testcase directory for an individual test for all test suites.
Bug: 193168159
Test: cts-tradefed run commandAndExit CtsBionicTestCases
Change-Id: If034723e8fe937ca71d3e2d39b7d46702e41bc8c
Robolectric tests are installed by Soong, which means Make doesn't
know about the install location to create the phony rules. Add
a phony rule in Soong for now until Soong's installation rules are
fleshed out.
Bug: 184946827
Test: m SettingsRoboTests
Change-Id: I60d76474949800e1a737714d86df84eff9a92214
* changes:
Consolidate the code to resolve a deapexer module dependency.
Propagate the dex jar path as an OptionalPath which is either valid or invalid with a message.
Historically, this file was used by the `--updatable-bcp-packages-file`
flag for dex2oat. The flag is no longer needed and is being deprecated.
Unfortunately, we cannot remove `permitted_packages` and all the code
related to it because we still need it for checking the module
compatibility with Q and R.
Bug: 200241946
Test: m nothing
Change-Id: Ie3be54fd47a847ba0caf627d12da76b415d99466
It will get more logic in upcoming CLs.
Add a property to DeapexerInfo for the APEX name, for use in error
messages.
Test: m nothing
Bug: 192006406
Change-Id: I957f3df8b34543a38cde38768dac93e78132d672
invalid with a message.
This will allow propagating any error from the deapexer module for
prebuilt APEXes to the location where the dex jars get used. It's only
at those points that we can raise errors about not being able to
extract files from the deapexer modules if they are invalid, and this
way we avoid encoding knowledge there about why they may be invalid.
To keep the refactoring limited it intentionally does not change any of
the existing logic for when dexJarFiles are set or not (non-nil vs nil
prior to this change), although there may be opportunity to use this
for more conditions when dex jars aren't available.
The refactoring is also not extended to
dexpreopt.ClassLoaderContextMap.
Test: m nothing
Bug: 192006406
Change-Id: I68986dccd9a9b3fee4d24caa1947ea17a36caedc
The annotations zip file is produced by the "main" sdk build and is
primarily consumed by android studio.
In order to support building the main SDK without requiring the sources
of all modules, we are adding module SDK artifacts that allows
reconstructing these outputs. The annotations zip contains XML files
which should be fairly easy to merge from all the individual parts.
Bug: 187397779
Test: unit tests in this CL
Test: m sdkextensions-sdk and inspect output
Change-Id: I955cae720e6f1382936836ee1d8fb11003f51b7d
So that the Windows build-tools package doesn't need to manually copy
the wrapper. Also fixes enabling java modules for Windows by hiding them
from Make, as the Make code does not handle Windows java modules
properly.
Bug: 187222815
Change-Id: I13534b38b9a9f4b5ff0630e028c3b4f88a6b34f8
When a module depends on the compose runtime add a -Xplugin argument
to the kotlinc flags that enables the compose compiler plugin.
Bug: 196351110
Test: TestKotlinCompose
Change-Id: I423a3c4d12df42804a24b672a40a165bc8dd165f
This arg provides the ability to pass sources to the metalava
invocations that are part of a java_sdk_library without affecting
the runtime library.
This is useful in various scenarios, e.g.: when javadoc in some source
files affects the metalava behavior. For example, the javadoc-generation
javadoc tags @paramDoc, @returnDoc etc. Passing these as a library does
not work because class files do not contain javadoc.
Bug: 186197911
Test: manually inspect module stub src for doc enhancements
Merged-In: I2ce98f891283514e1896c52d9335550c1f5435fb
Change-Id: I2ce98f891283514e1896c52d9335550c1f5435fb
When TARGET_BUILD_APPS is set then TARGET_BUILD_USE_PREBUILT_SDKS=true
which causes all java_sdk_library_import modules to be treated as
prefer:true.
That breaks the build when the systemserverclasspath_fragment's content
property references a source java_sdk_library module that has a
corresponding java_sdk_library_import prebuilt module.
This fixes the issue by marking the dependency from the
systemserverclasspath_fragment to the source module as one that must
not be replaced with a reference to the prebuilt module.
Test: - update art prebuilts to include service-art
m TARGET_BUILD_APPS=Calendar apps_only
- fails before, works afterwards
Bug: 199116972
Change-Id: Ia2d8ce7bb7e644336a42c901f7fb8ea50fd67909
Adds a test case to TestJavaStableSdkVersion for the case where a
module uses sdk_version: "core_platform" but is in the list of modules
that can use the legacy version.
This required storing the lookup map in the Config to allow it to be
customized for the test.
Bug: 180399951
Test: m nothing
Change-Id: I404705c3fd8a559649c6ab2624856cf78f49f85c
This reverts commit 92346c4832.
Reason for revert: Fixed build error.
The build error is fixed by ag/15841934. This CL remains unchanged. This
CL will be submitted AFTER ag/15841934 is submitted.
Bug: 200024131
Test: 1. Patch this CL and ag/15841934 into internal master.
2. sudo vendor/google/build/build_test.bash
Change-Id: I5f2b8357846fc7dda56e25ebe6ffb095e8047ec8
Previously, we preopt system server jars without updatable bootclasspath
in the build system so that the artifacts can keep valid after a
mainline update. Things have been changed after then. We now re-compile
system server jars on the user's device after a mainline update
(b/189467174), so we no longer need the artifacts generated at build
time to keep valid. Therefore, we can preopt system server jars with
updatable bootclasspath to achieve better performance.
Bug: 199573699
Test: m services
Test: manual - 1. Build a system image and flash it into a device.
2. adb root && adb shell grep "services" /proc/`adb shell pidof system_server`/maps
3. See "/system/framework/oat/x86_64/services.{odex,vdex,art} in the
output.
4. adb logcat -d odrefresh:D odsign:D "*:S"
5. See "odrefresh said artifacts are VALID" and no dex2oat invocation
in the output.
Change-Id: I9c94a54aa15c46708067f4bc89ff05bc7af32a7b
The path to the artifacts will in the form of
/system/framework/oat/<arch>/<encoded-jar-path>@classes.{odex,vdex,art},
where <encoded-jar-path> is the path to the jar file with "/" replaced
by "@". For example,
/system/framework/oat/x86_64/apex@com.android.art@javalib@service-art.jar@classes.odex
There will be a follow-up CL to update ART runtime to recognize
artifacts in that path.
Test: m com.android.art
Bug: 194150908
Change-Id: Ic89fd63c4b1cd565684cead83fc91dae3bc97a4c
Similar to the previous CL, but for jars from prebuilts.
Test: manual - 1. Patch aosp/1818020 and aosp/1810840.
2. m SOONG_CONFIG_art_module_source_build=false com.android.art
Bug: 194150908
Change-Id: Idc0c73a78045a602ad3a91cb5071d291bd611015
dep.OutputFile().Path() can panic if the OutputFile
is invalid, so move more of the code into the check
for validity. This changes the go crash into a
build error.
Bug: 158624492
Test: Apply the patchset 1 of ag/11815659, lunch aosp_x86_64-eng, m
Change-Id: Ic8a728be1b570ac73be7b2b9461676f9fd99c266
Make lint write a baseline file to the output directory that can be
used as a starting point when baselining new errors.
Bug: 197238141
Test: out/soong/.intermediates/cts/apps/CtsVerifier/cts-verifier-framework/android_common/lint/lint-report.html
Change-Id: I72033bb870bff5a72b648737219d11315fabf134
Don't uncompress priv-app dex for `android_app_import` if
DONT_UNCOMPRESS_PRIV_APPS_DEXS is true. Update expected test results.
Bug: 194504107
Test: m nothing
Change-Id: I4e7aa1a3deea856f388ae5ecd9292301f8a09a2f
Some of the test cases for privileged apps currently produce incorrect
results (e.g. with DONT_UNCOMPRESS_PRIV_APPS_DEXS := true); they are
marked with TODO and will be fixed in a follow-up CL.
Bug: 194504107
Test: m nothing
Change-Id: Ic0cd24113a27850a967afa0b3deb4a6324f95347
Replaces the BottomUpMutatorContext parameter with a new
SdkDependencyContext type that extends BottomUpMutatorContext. This is
to allow the sdk to pass additional information to the implementations
of that method to allow the behavior to be more finely tuned.
Bug: 195754365
Test: m nothing
Change-Id: I69c6d2c523934eb67d7a7e6c55c241e9b8a81773
Added SPDX-license-identifier-Apache-2.0 to:
java/core-libraries/Android.bp
mk2rbc/Android.bp
Bug: 68860345
Bug: 151177513
Bug: 151953481
Test: m all
Exempt-From-Owner-Approval: janitorial work
Change-Id: Iaf8546fc945b04b71cd5cb1c7c16a9e15f608d02
These are just out/ and out/soong/ and the old names were quite
confusing.
Test: Presubmits.
Merged-In: I999ca62162062f27e449f83ffb00fa580d4065b8
Merged-In: I2fcd80a9e376a6842a06aa104a9f6f5c5e16f8c7
Change-Id: Ib481d2aac40df8da1b74174dc8ec576c1cb48be0
Soong checks that every module part of a bootclass_fragment provides a
dex boot jar file, even if the module is not a dependency of vendor.img
Using AllowMissingDepdencies() to skip this check allows vendors to be
more aggressive in removing projects from their source tree
Test: In build/soong, run go test ./...
Test: m nothing
Bug: 196306898
Bug: 192616764
Change-Id: I78b062afdc19a6a3251aa8552230f3fcf334b6fb
These properties specify libraries that cannot be implicitly inferred by
Soong. If these properties are added to Android.bp, this can only be for
the reason that there is a <uses-library> tag in the manifest which is
unknown to the build system. Adding them to the manifest_fixer doesn't
make sense: if they are not in the manifest, they should be removed from
Android.bp as well.
Bug: 132357300
Test: $ lunch aosp_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: Ic6eb5268a954ef3be7f06a181ec72af99000c547
Automatically add `uses_libs`/`optional_uses_libs` properties specified
in `java_library` modules to the apps that transitively depend on these
libraries.
Note that a library may choose to specify its <uses-library> deps as
either optional or required. If this is not the right choice for an app,
it should be able to override it by specifying its own `uses_libs`/
`optional_uses_libs` properties.
Add Soong tests to cover the new cases.
Bug: 196377222
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Change-Id: I601f3e2830ed9699b78d911966ee70812d32b4f6
A performance improvement for bp2build as Blueprint/Soong no longer have
the overhead of additional modules. The creation of these modules
results in:
* traversal of additional modules for each subsequent mutator
* synchronization over a go channel to collect newly created modules:
https://cs.android.com/android/platform/superproject/+/master:build/blueprint/context.go;l=2594,2600;drc=1602226f23181b8c3fbfcaf3358f0297e839d7d3
We avoid both of these by storing the information directly in the
underlying module.
Also as a fringe benefit, removes some necessary boilerplate for
conversion.
For benchmarks, reduces runtime ~1% for 1% converted, ~24% for 100%
converted. See more: go/benchmarks-for-https:-r.android.com-1792714
Test: ran benchmarks/tests in bp2build
Test: build/bazel/ci/bp2build.sh
Change-Id: Ie9273b8cbab5bc6edac1728067ce184382feb211
Automatically add `uses_libs`/`optional_uses_libs` properties specified
in `android_library` modules to the apps that transitively depend on
these libraries.
Note that a library may choose to specify its <uses-library> deps as
either optional or required. If this is not the right choice for an app,
it should be able to override it by specifying its own `uses_libs`/
`optional_uses_libs` properties.
Bug: 196377222
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Change-Id: I1e36c56719c0023dcd25fa6aeb92016471702b9f
The source of truth for what jars are in BOOTCLASSPATH and
SYSTEMSERVERCLASSPATH is make; adding a classpath fragment in soong
with a new jar in the contents without having it declared in make
is wrong (excluding test apexes).
Bug: 191369843
Test: m nothing
Change-Id: Ifd313776ee7ad206031244534ed3870126e4f835
Previously manifest_fixer used a naive way to distiniguish optional libs
from required ones: it checked if a library is on the list of optional
compatibility libraries. This works for compatibility libs, but not for
other libs.
Now we properly track optionality through all stages of the build,
starting with the addition of the library as a dependency (here's where
the `uses_libs`/`optional_uses_libs` distinction kicks in), store it in
dependency tag and propagate to class loader context, and from there to
the manifest_fixer.
The tests have been updated accordingly.
Bug: 196377222
Test: lunch bertha_x86_64-userdebug && m droid dist cts mts
Change-Id: I3631ce59ebe47116ce7a9b3d33a86f636846ef0f
Previously, the sdk snapshot would include all the entries from the
stub-flags.csv and all-flags.csv modular files generated by a single
bootclasspath_fragment. That included implementation details, i.e.
class members that are not part of a stable API or the hidden API which
meant that the sdk snapshots were implementation dependent.
This change removes the implementation details from the modular flag
files, i.e. those entries that are only marked as "blocked". When
comparing the files against the corresponding subset of the monolithic
files it assumes that any entries missing from the modular flag files
are blocked.
Bug: 194063708
Test: atest --host verify_overlaps_test signature_patterns_test
m out/soong/hiddenapi/hiddenapi-flags.csv
- manually change files to cause difference in flags to check
that it detects the differences.
Change-Id: I6b67b2253cf029d6830b58a06ebb0c8fcaa0dd71
Lint reports were only being collected from jars in apexes, not
apps.
Bug: 188772607
Test: mainline_modules_arm64 build
Change-Id: Ie84819343f8b8ab3f43496bbc9b7876d0d0d8e70
This is in preparation to r.android.com/1740313 where setting correct
variables would be enforced (i.e. apex and non-apex boot jars must be in
config.ApexBootJars and config.BootJars correspondingly).
Bug: 191369843
Test: m nothing
Change-Id: Ic86680c1f7af53d229083b2cc58beb3ceccb4b6a
Bug: 194063708
Test: atest --host verify_overlaps_test signature_patterns_test
m out/soong/hiddenapi/hiddenapi-flags.csv
- manually change files to cause difference in flags to check
that it detects the differences.
Change-Id: Ic819def9b0c41e3b22fb98582cd39f6d27080a32
Previously, the signatures used to select the subset of the monolithic
flags were simply the signatures read from the modular flags file. This
change moves the creation of the signature list into a separate script
that outputs the signatures to a file and then passes the path through
Soong from the bootclasspath_fragment modules that create it to the
platform_bootclasspath module that uses it to compare the modular
flags against the monolithic flags.
Currently, the signatures are the full signatures but follow up changes
will replace them with patterns (hence the name) that avoids having to
include implementation details in the hidden API flags that are output
as part of a bootclasspath_fragment's snapshot.
This change moves the stub flags related code next to the all flags
related code as they are treated in a similar way.
Bug: 194063708
Test: atest --host verify_overlaps_test signature_patterns_test
m out/soong/hiddenapi/hiddenapi-flags.csv
- manually change files to cause difference in flags to check
that it detects the differences.
Change-Id: I2855bf6d05c91b8a09591664185750361c7e644f
R8 will parse proguard files out of resources in injars. Use the jar
with resources instead of the classes jar so that R8 can see the
proguard files.
R8 fails when an input jar contains dex files, so filter out dex files
from the input jar before passing it to r8.
This relands Ibb870ee9c70470336f542a3b7542dab86716dbf8 with a fix to
move the temporary input jar outside the output directory. Putting it
in the output directory interacted poorly with RBE in local comparison
mode, which incorrectly deleted the output directory.
Bug: 195558228
Test: m checkbuild
Change-Id: Id4b091c3bd72d4c2904883e8793ec4b9499e4b78
This reverts commit 29c294b2cf.
The deadlock in R8 was fixed, and the timeout causes problems when
RBE is enabled and the R8 action gets stuck in a queue for 30
minutes.
Test: checkbuild
Change-Id: Ia0c3826aea3288e9db3bdbd4955e1e16c0a38fe3
