aboutsummaryrefslogtreecommitdiff
path: root/sdk/java_sdk_test.go
Commit message (Collapse)AuthorAgeFilesLines
...
| * Always set apex_available in SDK snapshots.Martin Stjernholm2020-11-041-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | Also fix //apex_available:platform that could get lost in the generated apex_available properties. It only happened if a module didn't specify an apex_available setting and then got extra entries from apex.BaselineApexAvailable. Test: Build ART SDK with libnativeloader_lazy in the SDK, and check that the generated prebuilt module has //apex_available:platform (before https://r.android.com/1480559). Change-Id: I9df20aee63455932a7e558993f0f26769cb02792
* | Remove support for droidstubs in sdk/module_exportsPaul Duffin2020-11-101-142/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Use glob for java_sdk_library_import stub_srcsPaul Duffin2020-11-091-28/+28
|/ | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Make lots of tests run in parallel"Colin Cross2020-10-091-22/+0
| | | | | | | | | | This reverts commit 323dc60712491c71ccdc5363c42df61f0a192487. Reason for revert: Possible cause of test instability Bug: 170513220 Test: soong tests Change-Id: Iee168e9fbb4210569e6cffcc23e60d111403abb8
* Make lots of tests run in parallelColin Cross2020-10-061-0/+22
| | | | | | | | | | Putting t.Parallel() in each test makes them run in parallel. Additional t.Parallel() could be added to each subtest, although that requires making a local copy of the loop variable for table driven tests. Test: m checkbuild Change-Id: I5d9869ead441093f4d7c5757f2447385333a95a4
* Explicitly specify visibility in sdk/module_exports snapshotPaul Duffin2020-10-011-0/+69
| | | | | | | | | | | | | | | | | | | | | This change ensures that each prebuilt in a snapshot explicitly specifies its visibility even when that visibility is the current default. This is done for two reasons: 1. It simplifies a follow up change that adds visibility rules to an existing set of rules. 2. It ensures that the snapshots are independent of the current Soong default visibility. The latter is important because we intend to switch from modules being visible to everyone by default (i.e. //visibility:public) to only being visible to modules in the same package (i.e. //visibility:private). By making the snapshots of modules that do not specify any visibility explicitly specify that they are "//visibility:public" it ensures that the snapshots will not need to be changed when the default changes. Bug: 168301990 Test: m nothing Change-Id: Ia034f4a1e5124c17f46d73b0e9a6c5f2a251038e
* Allow java_sdk_library to specify doctags_filesPaul Duffin2020-09-281-0/+70
| | | | | | | | | | | | | When generating Javadoc the processor needs to be given information about the doctags that are present in the source. This change allows that information to be managed with the java_sdk_library that generates the stubs source from which the Javadoc is generated. Bug: 168301990 Test: Built offline-sdk-docs with and without the change and diffed them. The only difference was the timestamp.js file. Change-Id: I4adbeb0781bc2191461fec856ffa90ea185e7434
* Remove framework-modules naming schemePaul Duffin2020-09-111-6/+6
| | | | | | | | | The naming_scheme property was not removed as it may be useful for future when migrating to java_sdk_library. Bug: 168301990 Test: m nothing Change-Id: Ie97dd60355a207f1312a2dd910f1fb25b46fd737
* Reland: Deduplicate APEX variants that would build identicallyColin Cross2020-08-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | APEX variants that share the same SDK version and updatability almost always use identical command line arguments to build but with different intermediates directories. This causes unnecessary build time and disk space for duplicated work. Deduplicate APEX variants that would build identically. Create aliases from the per-APEX variations to the new shared variations so that the APEX modules can continue to depend on them via the APEX name as the variation. This has one significant change in behavior. Before this change, if an APEX had two libraries in its direct dependencies and one of those libraries depended on the other, and the second library had stubs, then the first library would depend on the implementation of the second library and not the stubs. After this change, if the first library is also present in a second APEX but the second library is not, then the common variant shared between the two APEXes would use the stubs, not the implementation. In a correctly configured set of build rules this change will be irrelevant, because if the compilation worked for the second APEX using stubs then it will work for the common variant using stubs. However, if an incorrect change to the build rules is made this could lead to confusing errors, as a previously-working common variant could suddenly stop building when a module is added to a new APEX without its dependencies that require implementation APIs to compile. This change reduces the number of modules in an AOSP arm64-userdebug build by 3% (52242 to 50586), reduces the number of variants of the libcutils module from 74 to 53, and reduces the number of variants of the massive libart[d] modules from 44 to 32. This relands I0529837476a253c32b3dfb98dcccf107427c742c with a fix to always mark permissions XML files of java_sdk_library modules as unique per apex since they contain the APEX filename, and a fix to UpdateUniqueApexVariationsForDeps to check ApexInfo.InApexes instead of DepIsInSameApex to check if two modules are in the same apex to account for a module that depends on another in a way that doesn't normally include the dependency in the APEX (e.g. a libs property), but the dependency is directly included in the APEX. Bug: 164216768 Test: go test ./build/soong/apex/... Change-Id: I2ae170601f764e5b88d0be2e0e6adc84e3a4d9cc
* Avoid creating APEX variant for sdk memberPaul Duffin2020-07-241-2/+2
| | | | | | | | | | | | | | | | Previously, an APEX variant was created for a module that was a member of an SDK just in case it had to be replaced with an APEX requested snapshotted version of that member. That was necessary because that was the only way to have APEX specific replacements. Since then a new method called ReplaceDependenciesIf() has been added which provides fine grained control over which dependencies are replaced. This change uses that new method to handle the replacements which allows the APEX variants to be removed. Bug: 161928524 Test: m nothing Change-Id: If3869dd6753dc182b099af566b20fbc9c9c6eff7
* Enforce the legacy core/platform API restriction.Pete Gillin2020-07-231-2/+2
| | | | | | | | | | | | | | | This change silently decides whether modules which depend on either sdkPrivate or sdkCorePlatform get the legacy or the stable version of the core/platform API, based on whether the module's name is on a hard-coded list or not. Test: m java Test: make a target from the list when its entry is commented out, which correctly fails Bug: 157640067 Change-Id: I15e5a6c2f07e73718803501d705de0d7ab9bec90 Merged-In: I15e5a6c2f07e73718803501d705de0d7ab9bec90 Merged-In: Iaa97ddaa015e8079fcb3426585c5101c7ec9e22a (cherry picked from commit c0f4373106d6c205d11e3bbd61085736de7ec2df)
* Generate module lib API and scope togetherPaul Duffin2020-07-201-2/+2
| | | | | | | | | | | | | | | | | | | | | Previously, due to limitations in metalava the module lib API and stubs source were generated separately. That limitation has since been removed so this change optimizes the generating code. Changes: * Add an annotation field to apiScope to contain the annotation that identifies the scope. * Rename droidstubArgs to extraArgs to better reflect that they are not passed to droidstubs. * Rename droidstubsArgsForGeneratingStubsSource to droidstubsArgs. * Remove droidstubsArgsForGeneratingApi and createStubsSourceAndApiTogether fields along with code that supports generating stubs source and the API separately. * Fix the module lib test. Test: m checkapi Bug: 161364853 Change-Id: I821886bb68645addf5ae9c96ed2f4f3649151d1a
* Disable all SDK snapshot generation tests on mac.Martin Stjernholm2020-07-151-21/+0
| | | | | | | | | | | | | We frequently miss putting in the per-test skip condition, and since mac isn't tested in presubmit this leads to build breakages and time consuming reverts. To avoid that this blanket disables all the SDK tests on mac. It's not used there and we got test coverage in many linux-based builds. Bug: 145598135 Bug: 161315642 Test: `go test -v ./sdk` in build/soong on mac and linux Change-Id: I2aea92fef2c0f8c2742396fe36610501dc5a6f0f
* Ensure that sdk/module_exports depends on source membersPaul Duffin2020-07-091-0/+51
| | | | | | | | | | | | | Previously, preferring a prebuilt of an sdk/module_exports's member would cause the sdk/module_exports to depend on the prebuilt instead of the source and cause problems with the build. This chance prevents the dependency from an sdk/module_exports to its members from being replaced with prebuilts. Bug: 160785918 Test: m nothing Change-Id: Iee4bcd438c11929e30fb5766701b05a0e89956d9
* Include resources in sdk snapshot of java library implPaul Duffin2020-06-241-1/+3
| | | | | | Bug: 159607838 Test: m nothing Change-Id: Ie7ddbffc3957f832abfadb27292c436e8e5dcbf3
* java_sdk_library: Add system-server scopePaul Duffin2020-06-151-0/+92
| | | | | | | | Bug: 155164730 Test: m nothing Merged-In: I49a2dab5c064b05f16691a3fae65f2b4ffc53bfd Change-Id: I49a2dab5c064b05f16691a3fae65f2b4ffc53bfd (cherry picked from commit 5a757b1ebbf52825e032b99ffc9f86474d0a8558)
* Split the core/platform API into stable and legacy versions.Pete Gillin2020-06-081-2/+2
| | | | | | | | For now, everything outside libcore still uses the legacy version. Test: treehugger Bug: 157640067 Change-Id: If5234e9ee533ff537926801a0af045d36b1caf01
* Copy removed.txt file to the snapshot correctlyPaul Duffin2020-06-021-11/+11
| | | | | | | | | | Previously, the code copied the current.txt file to both the current_api and removed_api properties. This change copies the removed.txt file to the removed_api property instead. Bug: 157980685 Test: m nothing Change-Id: Iad34e91051da43222d22c240c16f50887c43d73e
* java_sdk_library: Propagate shared_library to snapshotPaul Duffin2020-05-281-0/+13
| | | | | | | | | | | | | Passes the shared_library property through to the snapshot. It does not optimize away the default value in order to make it easier to invert the default value in future. The current default value was only chosen for convenience because most existing usages were already treated as shared libraries. It would be safer if modules had to opt in to be used as shared libraries. Bug: 155164730 Test: m nothing Change-Id: I33c7323f2389b44ed49cebe517ae2cce349117f1
* Correct module_lib scope namePaul Duffin2020-05-141-12/+12
| | | | | | | | | | | | The module_lib scope should be called module-lib in order to pick up the latest filegroup. Without it the API lint does not use a baseline and so reports issues with released and unchangeable APIs. It is also needed for the correct dist path. Test: m update-api Bug: 155164730 Change-Id: I7dbafd7164d5da600ca45c39a7f93a5a40027a1f
* java_sdk_library: Propagate naming_scheme to snapshotPaul Duffin2020-05-131-0/+67
| | | | | | Bug: 155164730 Test: m nothing Change-Id: Iec7c52d2102b6294540090f3c1e32bd9d8cc7da8
* java_sdk_library: Add sdk_version for API scopesPaul Duffin2020-05-131-1/+63
| | | | | | | | | Allow the sdk_version against which the stubs for a scope are compiled to be specified in the module on a per scope basis. Bug: 155164730 Test: m nothing Change-Id: I5881e5ee7c2169c30f544882344a60a602dae917
* java_sdk_library: Allow separate api/stubs source modulesPaul Duffin2020-05-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | The API file for a scope represents the differences between the API provided by that scope and that provided by the scope that it extends. On the other hand the stubs source for a scope represents the union of the API provided by the scope and the scope it extends (all the way back to public). Unfortunately, while metalava supports this behavior for scopes that extend public (e.g. system and test) it does not support this behavior for scopes that extend others, e.g. module_lib which extends system. This is because it always assumes that the baseline for the API file is 'public' and so has no way to defined other baselines. This change works around that by having separate droidstubs modules to generate the API and stubs sources for scopes that require different arguments to generate the API and stubs sources. Test: m checkapi Bug: 155164730 Change-Id: Iea7d59852d7aeb503120acf3c44e08eb0d9d07b9
* java_sdk_library: Preserve sdk_version: "none" in snapshotPaul Duffin2020-05-121-0/+59
| | | | | | Test: m nothing Bug: 156354511 Change-Id: Icf7c20dc109a773430768c1a2d91c674551dbc1b
* java_sdk_library: Specify visibility of stubs modulesPaul Duffin2020-05-081-0/+2
| | | | | | | | | | | Adds two new properties to specify the visibility of the stubs modules (source and library) created by the java_sdk_library. Excludes visibility property from being inherited when creating the module so it can be properly specified by copying across the relevant property. Test: m checkapi Bug: 155164730 Change-Id: Iffdd9f191ff0d74646356ac577560cc38efdd790
* java_sdk_library: Add support for module_lib API surfacePaul Duffin2020-05-081-0/+111
| | | | | | | | | | | | | | Adds api scope for the module_lib and adds that to the list of all all available scopes. The scope is generated if and only if the api_surfaces property contains "module_lib". No other changes are needed as the generation of the APIs is completely driven by the allApiScopes array and the information in its contained apiScope structures. Test: m checkapi Bug: 155164730 Change-Id: I7769af6823badca8715a270f86cf53b4e954b7df
* java_sdk_library: Control API surfaces generatedPaul Duffin2020-05-081-0/+85
| | | | | | | | | | | | | Adds a per scope set of properties that allows explicit control over the API surfaces generated. Previously, the term active was used to determine whether it was generated but that was a little abstract and unclear so has been replaced by generated. Test: m nothing Bug: 155164730 Change-Id: I7539d89618b61f6b9d1a4b60cc3f9614b157f0d9
* Fix definition of android_stubs_current in sdk testsPaul Duffin2020-04-291-3/+3
| | | | | | | | | | This change fixes an issue with the definition of the android_stubs_current (and similar) modules in the sdk tests. They were incorrectly defined as java_sdk_library_import and not java_import. Test: m nothing Bug: 155164730 Change-Id: I4e9bfebdd2ff0a374e12284ccdf5ee5518968969
* Export API files as part of the java_sdk_libraryPaul Duffin2020-04-091-0/+18
| | | | | | | Bug: 153443117 Test: m nothing Change-Id: I9d6f5b91a7cc25019e2eb9e3c138f0874d2831de
* Export stub sources as part of the java_sdk_libraryPaul Duffin2020-04-091-2/+12
| | | | | | | | | Minor refactoring of checkMergeZip(string) -> checkMergeZips(...string) to allow testing of multiple merge zips. Bug: 153443117 Test: m nothing Change-Id: I8db00f611ced15f8476ba16f2834a72e8c913596
* Support java_sdk_library as member of sdkPaul Duffin2020-04-091-0/+112
| | | | | | Bug: 153443117 Test: m nothing Change-Id: I9d8089b2555038e3f10ad5939a6a7b01839c67ea
* Stop requiring apex_available on java_library members of sdksPaul Duffin2020-04-081-12/+0
| | | | | | | | | | | | | | | Previously, adding java_library to an sdk required that the names of any APEXes that transitively compiled against it were added to its apex_available property. This change removes that requirement. Also corrects the dependency path in the TestApexAvailable_IndirectDep error which previously passed through "shared from static" static dependency tags even though those are explicitly NOT followed when checking apex_available settings. Bug: 152878661 Test: m droid Change-Id: I995ed38956c1bc210b09494812de012fed9f9232
* Output properties before sets in snapshot modulePaul Duffin2020-03-131-1/+1
| | | | | | | | | | | | | This ensures a consistent output irrespective of whether property sets are created before or after the properties are added. This provides a little more flexibility in the creation code which allows that to be simplfied. Also switches from using reflection to a type switch. Bug: 142918168 Test: m nothing Change-Id: Ia025bfc751f1217d1658de6fb8e15091ea0ea9ff
* Allow sdk members to vary by os typePaul Duffin2020-03-101-0/+123
| | | | | | | | | | | | | | | | | | Adds support for specifying separate members to an sdk/module_exports for different os types, e.g. separate ones for android and host. Adds 'android:"arch_variant"' tag to the dynamically generated fields for the sdk member types. Merges the exported members from all variants together. Determines the device/host_supported flags of the member snapshots by whether the OsClasses used by their variants rather than the sdk's host/device supported properties as they may be different. Bug: 150451422 Test: m nothing Change-Id: I41fbbcd8723aafd54826aad9b78eced9f66ef51c
* Add support for multiple os typesPaul Duffin2020-03-091-0/+66
| | | | | | | | | | | | | | | | | | | | | Updates the member snapshot creation code to support multiple os types. It basically sorts the variants by os type, then applies the code to optimize the arch properties and then it optimizes the properties that are common across architectures and extracts any properties that are common across os types. The java and cc member types needed to be modified to make the location of the generated files within the snapshot os type dependent when there is more than one os type. That was done by adding an OsPrefix() method to the SdkMemberPropertiesBase which returns the os prefix to use when there is > 1 os type and otherwise returns an empty string. Added three tests, one for cc shared libraries, one for cc binary and one for java header libraries. Bug: 150451422 Test: m nothing Change-Id: I08f5fbdd7852b06c9a9a2f1cfdc364338a3d5bac
* Add CommonOS variant for sdkPaul Duffin2020-03-021-12/+12
| | | | | | | | | | | | | | | | | | | | | | Adds a CommonOS variant for sdk that depends on the os specific variants and is used to generate a single sdk for multiple OsTypes, e.g. host linux and android. At the minute the member types only support a single OsType but the basic mechanism for managing the CommonOS variant and collating the variants across all of them is there. The only visible effect of this change is that the location of the generated snapshot is changed, it is no longer os specific and instead is in the same location irrespective of which os it is built for. A lot of tests needed to be changed to specify "common_os" as the variant type instead of the specific os type. As that is the same across all tests it is hard coded in CheckSnapshot method. Test: m nothing Bug: 150451422 Change-Id: If36be39b06d6910453649f7c288c2d34f688b2f4
* Differentiate between exported and internal sdk membersPaul Duffin2020-02-071-7/+41
| | | | | | | | | | | | | | | | | | | Internal sdk members are used by an sdk member but not exported by the sdk. The exported sdk members are those listed explicitly in one of the sdk member list properties, e.g. java_header_libs. The prebuilts of an internal sdk member use a unique name so that they do not clash with the source module. The use of the module internally is an implementation detail that must not have any effect outside the snapshot. Having the same name as the source module could cause it to override the source module, hence why it needs a unique name. Similarly, they are marked as private so as to prevent their accidental use from outside the snapshot. Bug: 142940300 Test: m nothing Change-Id: Id5364b410be0592f65666afb3e40e9d3f020251c
* Add java_system_modules to sdk/module_exportsPaul Duffin2020-02-071-0/+133
| | | | | | | | | | | | | | | Adds an SdkMemberType implementation for java_system_modules. It specifies that java_system_modules can be used with sdk as well as module_exports, and also that the libs property should be included as transitive members in the sdk. It also adds support for treating appropriate tagged properties in the snapshot prebuilts module as references to sdk members so that they are correctly transformed when creating the versioned modules. Bug: 142940300 Test: m nothing Change-Id: Ic10b5a6d5b92b6018334fe876f06feaf79cc55e9
* apex_available tracks static dependenciesJiyong Park2020-02-061-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change fixes a bug that apex_available is not enforced for static dependencies. For example, a module with 'apex_available: ["//apex_available:platform"]' was able to be statically linked to any APEX. This was happening because the check was done on the modules that are actually installed to an APEX. Static dependencies of the modules were not counted as they are not installed to the APEX as files. Fixing this bug by doing the check by traversing the tree in the method checkApexAvailability. This change includes a few number of related changes: 1) DepIsInSameApex implementation for cc.Module was changed as well. Previuosly, it returned false only when the dependency is actually a stub variant of a lib. Now, it returns false when the dependency has one or more stub variants. To understand why, we need to recall that when there is a dependency to a lib having stubs, we actually create two dependencies: to the non-stub variant and to the stub variant during the DepsMutator phase. And later in the build action generation phase, we choose one of them depending on the context. Also recall that an APEX variant is created only when DepIsInSameApex returns true. Given these, with the previous implementatin of DepIsInSameApex, we did create apex variants of the non-stub variant of the dependency, while not creating the apex variant for the stub variant. This is not right; we needlessly created the apex variant. The extra apex variant has caused no harm so far, but since the apex_available check became more correct, it actually breaks the build. To fix the issue, we stop creating the APEX variant both for non-stub and stub variants. 2) platform variant is created regardless of the apex_available value. This is required for the case when a library X that provides stub is in an APEX A and is configured to be available only for A. In that case, libs in other APEX can't use the stub library since the stub library is mutated only for apex A. By creating the platform variant for the stub library, it can be used from outside as the default dependency variation is set to the platform variant when creating the APEX variations. 3) The ApexAvailableWhitelist is added with the dependencies that were revealed with this change. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
* Default apex_available to //apex_available:platformAnton Hansson2020-01-161-0/+4
| | | | | | | | | | | | | | | | This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
* Add support for java_test in sdkPaul Duffin2019-12-311-0/+106
| | | | | | | | | | | Adds java_test_import module type for use by the sdk snapshot and adds java_tests property to the sdk and sdk_snapshot module type. This is needed for the conscrypt test sdk. Bug: 143678475 Test: m nothing Change-Id: Ied4c56c978dac2f92a9b3bc34b3235d7eeba2fd3
* Restrict SdkMemberTypes that can be used with sdk/sdk_snapshotPaul Duffin2019-12-311-30/+30
| | | | | | | | | | | | | | By default SdkMemberTypes are only supported on module_exports module type. Support for sdk module type has to be explicitly specified. The java_header_libs, native_shared_libs and stubs_sources are supported on sdk. The latter is required to provide the stubs source for an API specified in java_header_libs as they should be kept in sync. Bug: 146341462 Test: m nothing Change-Id: I19b9e60792780a797458d4a9e489506602b13144
* Ensure prebuilt modules have same visibility as source modulesPaul Duffin2019-12-091-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Exports visibility and package mutator registration functions so they can be used in sdk testing. Updates sdk test to support visibility and package modules. Adds EffectiveVisibility(...)[]string function to make the effective visibility rules available to sdk snapshot creation. Extracts compositeRule.Strings() []string from compositeRule.String() method so that it can be used by above func. Adds visibility property to sdk snapshot and prebuilt modules along with a test to ensure it works properly. Adds dir parameter to CheckSnapshot so that it can check the snapshot generated for a non-root package. That is required in order to ensure that visibility of :__subpackages__ on a source module in package <pkg> is resolved to an effective visibility of //<pkg>:__subpackages__ on its corresponding prebuilt. Test: m conscrypt-module-sdk Bug: 143678475 Change-Id: Icaacac5b9c04726d28e6fec93e49715ac45df7f4
* Support header and implementation jars in sdkPaul Duffin2019-12-061-6/+115
| | | | | | | | | | | | | | Add a new java_header_libs property that exports header jars (as java_libs currently does) and switch java_libs to export implementation jars instead. Refactors implementation of the existing library sdk member type so both properties can be supported from common code as they differ only on the jar being exported. Bug: 143678475 Test: m nothing Change-Id: I04642122f72d083bbdfd3290624f957b71ee8875
* Separate out module type specific test configPaul Duffin2019-12-061-6/+26
| | | | | | Bug: 143678475 Test: m conscrypt-module-sdk Change-Id: I71433a7c89dfae4c27537f1f66bd677cf9fba0b3
* Extract the cc and java sdk related tests out into their own filePaul Duffin2019-12-061-0/+332
Makes it easier for multiple people to work on different areas without conflicts. Bug: 143678475 Test: m conscrypt-module-sdk Change-Id: I93140450c0b049946a9d0432225bccff82f5a873
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-20 14:31:06 +0000