summaryrefslogtreecommitdiff
path: root/java/testing.go
AgeCommit message (Collapse)Author
2023-05-12Unify installDirOnHost and installDirOnDevice. Jiakai Zhang
These two fields never do what they are described to do. This CL unifies them to avoid the confusion. Bug: 280440941 Test: m (cherry picked from https://android-review.googlesource.com/q/commit:09d88df0407263e846b01c226184b262f2e36678) Merged-In: I3652d73a50832a2e494d9f5cae750f5fc38293b4 Change-Id: I3652d73a50832a2e494d9f5cae750f5fc38293b4
2023-05-12Prepare tests for dexpreopt changes. Jiakai Zhang
After this change, there is a clear separation between tests that are related to dexpreopt and tests that are not. The former uses PrepareForTestWithDexpreopt, while the latter uses PrepareForTestWithJavaDefaultModules. The benefit is that the latter will no longer affected by any dexpreopt changes. Bug: 280776428 Test: m nothing (cherry picked from https://android-review.googlesource.com/q/commit:b95998be731406209f18fab764b96421a17ab4c9) Merged-In: Ib957765b9287d51c082e0a33cee17a6bb56daeef Change-Id: Ib957765b9287d51c082e0a33cee17a6bb56daeef
2023-04-17Add additional java_api_library module to java testing Jihoon Kang
Module lib surface is comprised of contributions from art, conscrypt, and i18n api domains. On top of this, the module lib api surface generates an additional stub library containing the contributions of the non-updatable api domains. Adding this additional module to the testing module enables more thorough testing of module lib api scope java_api_library modules. Test: m Change-Id: Ia648651fb9e6cba2642de7e8d39047d888bf49ce
2023-04-04Update java_api_library in testing modules Jihoon Kang
The full api surface java_api_library modules are currently defined as java_library modules instead of java_api_library modules. This change corrects this and modifies the DepsInfo of java_api_library so that it can be compatible in tests. Test: go ./java Change-Id: I540b5a930f506ce5f7663ab6e07c6df49af15cf9
2023-03-30add *.from-text modules to the java test fixture Spandan Das
Test: go build ./java Change-Id: Ib9ff4eb59ff63dc208b7a28626d42b53153c86d6
2023-02-28Replace SortedStringKeys with SortedKeys Cole Faust
Now that we have generics. Bug: 193460475 Test: presubmits Change-Id: I1594fd8feb505175d5c09c03ef397e5ffd5b09cb
2022-12-10Always run AndroidGlobalLintChecker.jar with lint invocations mattgilbride
AndroidGlobalLintChecker.jar provides a set of lint checks that should be run across the entire tree. Bug: 236558918 Test: manually tested, treehugger Change-Id: I2a868f1d78c969eefa2c29477fc8ecab1043df39
2022-12-01Merge "Support testing for resource shrinking" Treehugger Robot
2022-10-06Test bootImageConfig/Variant fields Paul Duffin
Most of the fields in the bootImageConfig/Variant structs are assigned inside a Once func so are guaranteed to be only set once. However, some are assigned outside. This change adds comprehensive tests for those structs and verifies that the constant fields are preserved and the mutated fields have the correct value. The check for the constant fields is added in a new TestBootImageConfig test. The check for the mutated fields is added into TestSnapshotWithBootclasspathFragment_ImageName as that test checks an art bootclasspath_fragment in the following configurations: * source on its own * prebuilt on its own * source and prebuilt with source preferred * source and prebuilt with prebuilt It reveals a couple of interesting facts: * All the *installs fields are set to the same value irrespective of whether the source or prebuilt is preferred. The information is constructed solely from information already within the bootImageConfig/Variant and so can be moved within Once. * The licenseMetadataFile is incorrect when prebuilt is preferred. That is due to both the source and prebuilt modules setting it and the source module always wins as the source module depends on the prebuilt so always runs its GenerateAndroidBuildActions after it. Those issues will be cleaned up in following changes. Bug: 245956352 Test: m nothing Change-Id: If917cfbcb3b1c842a8682d51cc1ee1fed1c51add
2022-09-28Support testing for resource shrinking Jared Duke
Add a simple test and add necessary mock dependencies to allow future resoure shrinking use with platform targets. Test: m Bug: 202959019 Change-Id: Id2dd44d52ce5ea62c06784caab0af6276248cb3f
2022-09-09add jacocoagent by default to Java modules Sam Delmerico
On coverage builds, R8 will fail to properly optimize and fail the build if ignore_warnings: false, because jacoco injects dependencies on jacocoagent classes, but the jacocoagent library is not part of the classpath libraries passed in to R8 in its arguments. Instead we can add jacocoagent as a libs dependency for these modules so that it will get pulled into the r8 flags. Bug: 243903417 Test: m Change-Id: Icc24cc260b896fc800125a0318308d823ccf7a83
2022-04-12Merge changes I046d75db,Ie13817dc am: d2aa190bdc am: f2c86c8c76 am: 1a3ea67458 Colin Cross
Original change: https://android-review.googlesource.com/c/platform/build/soong/+/2058908 Change-Id: I9ab91976903abbb4e3ec17b3d26db15447f074d6 Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
2022-04-11Move proguard test files to java package Colin Cross
The proguard test files are duplicated in apex and sysprop and will be needed by app tests, move them to the java package. Test: run all soong tests Change-Id: Ie13817dcda8d98801d16a97ffceef1100c7d5380
2022-04-05Surface Java APIs Used By APK-only Modules. Matt Banda
Previously we were only generating used-by API-coverage for APEX modules. This change adds support for APK-only modules such as NetworkStack and DocumentsUI. Bug: b/216313756 Forrest Run: https://android-build.googleplex.com/builds/abtd/run/L10800000953846781 Test: TARGET_BUILD_VARIANT=userdebug PRODUCT=mainline_modules_x86 ./vendor/google/build/build_unbundled_coverage_mainline_module.sh -j16 Change-Id: Id17e4a55c2a52e9903632a654e778f8d54982dfc Merged-In: Id17e4a55c2a52e9903632a654e778f8d54982dfc (cherry picked from commit 56d75785bd52c8a8f684935eed67fceb2c0e6850)
2022-02-21Add support for sdk extensions in prebuilt_apis Anton Hansson
This makes it possible to pass an extensions_dir containing finalized module APIs to prebuilt_apis. The extension versions are compared to the api level versions to figure out what the "latest" finalized API is for each module. This is done using the base_sdk_extension_version, such that any extension higher than than base_sdk_extension_version is assumed to be finalized after any of the existing api level versions. Bug: 220086085 Test: prebuilt_apis_test.go Test: existing module in prebuilts/sdk Change-Id: Ib792f84202d436f594ba5e8716c6a187f9cd60dc
2022-01-13Allow installing boot images outside of APEX. Jiakai Zhang
After this change, `bootImageConfig.installDirOnDevice` can be set to a path outside of the APEX, in which case, the boot image will not be installed in the APEX. Instead, it will be installed to the given path by Make. This is a no-op change. Current behavior is not affected. Bug: 211973309 Test: m nothing Test: - 1. m com.android.art 2. See the boot image still being installed in the ART APEX. Test: - 1. Change `installDirOnDevice` of the ART boot image config to `system/framework`. 2. See the boot image being installed in `/system/framework/<arch>`. Change-Id: Ib13b17cc9e94dc5754c9b51b04df3307323b8783
2021-11-03Rename core-current-stubs-system-modules to be more consistent Paul Duffin
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
2021-11-01Use module-lib system modules when building from prebuilts Paul Duffin
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
2021-11-01Make prebuilt_api test environment realistic Paul Duffin
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
2021-10-29Run TestClasspath test cases with Always_use_prebuilt_sdks=true/false Paul Duffin
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
2021-09-22Add annotations.zip support to java_sdk_library Anton Hansson
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
2021-09-20Merge "Add test to TestJavaStableSdkVersion for legacy core platform" Treehugger Robot
2021-09-16Add test to TestJavaStableSdkVersion for legacy core platform Paul Duffin
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
2021-09-16Revert^2 "Preopt APEX system server jars." Jiakai Zhang
This reverts commit 92346c483249726164f4bd140413d60391121763. 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
2021-09-15Revert "Preopt APEX system server jars." Adrian Roos
This reverts commit ca9bc98e0cfe9a519cfdd13450a68f1ed7ad5b02. Reason for revert: breaks build Bug: 200024131 Change-Id: Ide07b4c4d267370ae31107b1598b2f878c701282
2021-09-15Preopt APEX system server jars. Jiakai Zhang
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
2021-07-22Rename UpdatableBootJars to ApexBootJars. satayev
Note that ART apex boot jars and core-icu4j are exceptions here as they are not part of ApexBootJars. ART apex boot jars are defined in their own variable, while core-icu4j is treated as a regular non-updatable boot jar. Bug: 191127295 Test: atest CtsClasspathsTestCases Change-Id: I3cea3d82ef521655a1a5ffa8cae2258ab9d08bfc
2021-06-29"module_current" and "system_server_current" should contain ART's ↵ Victor Chang
@SystemApi(MODULE_LIBRARIES) Before this fix, compiling a java_library against sdk_version: "module_current" can't use the @SystemApi(MODULE_LIBRARIES) provided by the ART module because the system module "core-current-stubs-system-modules" contains only the public APIs. Use the new system module with module lib APIs. Bug: 183097033 Test: m droid Change-Id: I274e2710d1ff34e896aa620bfafb4481180c53b5
2021-06-22Append platform classpath proto configs with missing apex jars. satayev
Any apex classpath fragment that doesn't generate its own classpaths proto, must still propagate it's boot jars for the platform classpath fragment to include for complete CLASSPATH variables on device. Bug: 191127295 Test: atest CtsClasspathsTestCases derive_classpath_test Change-Id: I93687f69006741fcd66eb6e04891a4b4bbcc3b47
2021-06-20Make CheckHiddenAPIRuleInputs more reusable Paul Duffin
Adds a message parameter and allows leading spaces in the expected file string to allow them to be nicely indented. Bug: 177892522 Test: m nothing Change-Id: I33df26610738c48879fa0b8250dc377dd04bb07d
2021-05-20Merge changes I4e7a7ac5,I0c73361b Jiyong Park
* changes: Record the actual APEXes that a module is part of. Rename InApexes -> InApexVariants
2021-05-18Don't fail if the target module is disabled in dex2oat tool Martin Stjernholm
dependencies. dexpreopt.RegisterToolDeps runs late after prebuilt dependencies have been resolved, and there's special code in dex2oatPathFromDep to resolve the prebuilt from the source module. However, if the source module is disabled then the dependencies check in validateAndroidModule will complain, so we need to disable that check in this particular situation. Also add a comment to explain why dexpreopt.RegisterToolDeps needs to run so late. Test: m nothing Bug: 145934348 Bug: 172480615 Change-Id: Ibc673303d0336768fa23261a2068e91a08f46a30
2021-05-18Rename InApexes -> InApexVariants Jiyong Park
.. in preparation for the upcoming change. This change doesn't alter any behavior. InApexes is a misleading name. People expects that it has the list of soong module names of the APEXes that a module is part of. So, for example, `core-oj` is a part of both `com.android.art` and `com.google.android.art`. However, in reality, that's not true. The field has `com.android.art` only. This is because the two APEXes (android and Google) have the same apex name which is `com.android.art`. That apex name is used in various places like the `apex_available` and allows us to keep using the same name regardless of whether the APEX is overridden or not. However, this is causing problems in some cases where the exact list of soong module names is required. The upcoming change will add a new field to handle the case and the new field actually will get the name 'InApexes'. So, the existing field is renamed to a less misleading name `InApexVariants`. Bug: 180325915 Test: m nothing Change-Id: I0c73361b452eddb812acd5ebef5dcedaab382436
2021-05-10Strict updatability linting against dependencies. Jaewoong Jung
Propagate strict_updatability_linting to transitive dependencies using a top-down mutator. Test: lint_test.go Bug: 182349282 Change-Id: Ifc9e58f1a597e3c7725ee49b4027afb6f42f45cb
2021-05-07Split SYSTEMSERVERCLASSPATH entries from platform_bootclasspath. satayev
Boot jars are different to system server jars at build level, due to added complexity of dexpreopt. As a logical separation add a new classpath fragment type and split existing classpaths.proto generation into relevant pieces. Bug: 180105615 Test: m && launch_cvd; atest CtsClasspathsTestCases Change-Id: I88bec09fc920166ffd0092faef980754ddeb6593
2021-04-23Rename BootImageModule to BootclasspathFragmentModule Paul Duffin
Also renames files, tests, module types in a similar fashion. There are still some references to image and boot image. They are kept for the following reasons: * image_name - this is the name of an ART boot image, i.e. the collection of .art/.oat/.vdex files. * BootImageInfo - again this is related to the ART boot image. * .../art_boot_images/... paths - ditto. Bug: 177892522 Test: m nothing Change-Id: Ie1f4738061d131fee75de48bc26a7601481bad4d
2021-04-23Generalize the platformBootclasspathDepsMutator Paul Duffin
Adds a BootclasspathDepsMutator that is currently only implemented by the platform_bootclasspath but which can be implemented by bootclasspath_fragment too. Bug: 177892522 Test: m nothing Change-Id: Ibe35854281004d6e40bf1f797144fb582e8c08b9
2021-04-21bootclasspath_fragment: Add contents to snapshot Paul Duffin
Bug: 177892522 Test: m nothing Change-Id: I54fe0537b758a0e3dacd34b139ef3eb21b8841fd
2021-04-13Improve realism of boot jar tests Paul Duffin
Boot jars, updatable boot jars and art apex jars are part of two separate but related configuration objects, the main Config struct (actually the nested productVariables struct) and the dexpreopt specific GlobalConfig. The fields in both are initialized from the same data in the make config files but handled separately. Previously each test that used one of the configuration objects would generally just initialize the one it used. That would make the test sensitive to the specific configuration object that was used. A refactoring that change the code from using one configuration object to the other would cause the test to fail. Also, some tests would inadvertently create invalid configurations by setting ArtApexJars without also setting BootJars. While the ability to create invalid configurations is useful (and there are some tests that exist to verify the behavior in that case) most tests should not be using them. This change simplifies the configuration of the tests and improves their realism by: 1. Providing a new FixtureConfigureBootJars method that takes a set of boot jars and sets ArtApexJars, and BootJars in the dexpreopt.GlobalConfig and BootJars in the product variables too. 2. Providing a new FixtureConfigureUpdatableBootJars method that takes a set of boot jars and sets UpdatableBootJars in both the dexpreopt.GlobalConfig and productVariables. 3. Migrating existing tests to use these new methods. Some tests still use the dexpreopt.FixtureSet...Jars() methods directly, generally to create invalid configurations. Bug: 177892522 Test: m nothing Change-Id: I4d8f0b9762cfcc7ae6383bef08563d7c3fa13955
2021-04-08Allow platform_bootclasspath to specify contributing fragments Paul Duffin
Adds the fragments property to the platform_bootclasspath to allow the fragments that contribute to it to be specified. Bug: 177892522 Test: m nothing Change-Id: I14f83d9336f6984442c7315cc86dfdd0a0fd2d20
2021-04-08Add dependencies from platform_bootclasspath to contents Paul Duffin
Adds a FinalDeps mutator to add dependencies from the platform_bootclasspath to the configured boot jars which can be from either the platform or any apex. It adds dependencies for every configured boot jar, whether in ArtApexJars, BootJars or UpdatableBootJars. At the moment the dependencies are only used for testing purposes but following changes will make more use of them. Bug: 177892522 Test: m nothing Change-Id: I981305bf45bc20539a3d36987252f490e2b885cc
2021-03-31Add a new platform_bootclasspath module type Paul Duffin
Initially, this is just a placeholder but functionality will be added in follow up changes. Bug: 177892522 Test: m nothing Change-Id: I890b0d5a117c51a19c9ac5df98c766761d3aa16c
2021-03-31Remove unused java testing methods Paul Duffin
Also, stops exporting methods that are no longer used outside the java package. Bug: 181070625 Test: m nothing Change-Id: I23d35bbc21f82f2dae802aa53badda4c58b41024
2021-03-24Convert test that disallows non existent paths to use fixtures Paul Duffin
This change needed to add some additional files to the registered files for PrepareForTestWithJavaDefaultModules because otherwise they would fail when "TestAllowNonExistentPaths = false". Those files were being added by the TestJavaLintRequiresCustomLintFileToExist (albeit in some cases in different locations to that required by the default modules but as the files are needed by the modules defined in PrepareForTestWithJavaDefaultModules they should be defined in it. A couple of other places also provided some files so moving them into PrepareForTestWithJavaDefaultModules caused some conflicts which needed to be resolved. Bug: 183184375 Test: m nothing Change-Id: I76ce9f1673c1c1c4000635b76b8377d582224bf1
2021-03-24Group all the preparations needed for testing dexpreopt Paul Duffin
Make it easier to test dexpreopt functionality by grouping all the fixture preparations together. Bug: 177892522 Test: m nothing Change-Id: I94f66e3ec82efc4fd791f4fdab678d298565e452
2021-03-24Separate methods used for fixture based and legacy tests Paul Duffin
The fixture mechanism makes it easy to refactor by splitting up an existing preparer into separate ones and then combining them back together. Unfortunately, that becomes slightly more tricky when preparers and legacy tests use the same functions to register build components and define default modules. This change splits the RegisterRequiredBuildComponentsForTest and GatherRequiredDepsForTest methods into two methods each, with the existing method used for legacy tests and calling the new method that is used for the preparer. At the moment all the functionality is in the new methods but over time, as functionality is extracted into separate preparers, the functionality can also be moved from the method that is common to both legacy and fixture based tests into the legacy only method. Bug: 177892522 Test: m nothing Change-Id: I233a4fe1fb072a00292acc2bb20821ec82a9bd67
2021-03-24Register java_plugin in PrepareForTestWithJavaBuildComponents Paul Duffin
Bug: 182885307 Test: m nothing Change-Id: I550d39ba46c548b6b099d8dc6a9c458ca931b2fa
2021-03-23Merge "Add platform_compat_config to sdk" Paul Duffin
2021-03-22Add preparer for overlay pre-singleton registration Paul Duffin
It appears as though this is the first pre-singleton type to actually be registered with the InitRegistrationContext as it failed due to an uninitialized map, so this change also fixes that. Bug: 182885307 Test: m nothing Change-Id: Ibbf6d0db5f3c2fcc89291a16aa5f16b8b5009bd3
2021-03-22Add platform_compat_config to sdk Paul Duffin
Bug: 182402754 Test: m nothing Change-Id: Ife3f4f64fc116d62eb7c3cc10c50e00f19d1d81c
generated by cgit v1.2.3-59-g8ed1b (git 2.39.0) at 2025-12-06 05:23:33 +0000