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
