aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/android/AndroidLocalTestBase.java
Commit message (Collapse)AuthorAge
* Remove ApplicationManifestGravatar asteinb2018-08-08
| | | | | | | | | | | | This class just contains methods used elsewhere; move them to appropriate places (generally AndroidManifest or StampedAndroidManifest). Also, somewhat reduce code duplication by having more stuff use the existing AndroidManifest.from() method, which automatically handles unspecified manifests and packages. RELNOTES: none PiperOrigin-RevId: 207913410
* Expose GeneratedExtensionRegistryProvider to Skylark.Gravatar Googler2018-08-08
| | | | | RELNOTES: None PiperOrigin-RevId: 207905848
* Remove analysis code for old resource processing pipelineGravatar asteinb2018-08-07
| | | | | | | | This code should all be unused now. Some code it calls into will be removed in the next changes. RELNOTES: none PiperOrigin-RevId: 207753966
* Add configuration for android data binding v2.Gravatar corysmith2018-08-06
| | | | | RELNOTES: None PiperOrigin-RevId: 207592136
* Moved all external calls to isDataEnabled to DataBindingContext and made it ↵Gravatar corysmith2018-08-03
| | | | | | | private. RELNOTES: None PiperOrigin-RevId: 207335684
* Reduce and centralize databinding context instances.Gravatar corysmith2018-08-03
| | | | | | | Due to some of the vagaries of skylark and multiple entry points, the databinding context is currently updated by the parse action. RELNOTES: None PiperOrigin-RevId: 207333111
* Automated rollback of commit 38899f708923d6a7e1edd011af2ba70f505bb4c9.Gravatar twerth2018-08-01
| | | | | | | | | | | | | | | *** Reason for rollback *** Necessary for [] *** Original change description *** Return Java providers only once through JavaInfo, instead of returning them also through ConfiguredTarget. Since these providers can not be found in ConfiguredTarget anymore they have to be retrieved from JavaInfo instead. RELNOTES: None. PiperOrigin-RevId: 206915058
* Add JavaSourceInfoProvider to JavaInfo.Gravatar elenairina2018-07-31
| | | | | | | | | JavaSourceInfoProvider is returned through JavaInfo instead of ConfiguredTarget for all Java rules. Only android_library and android_binary return it directly through ConfiguredTarget, since they don't return a JavaInfo provider. RELNOTES: None. PiperOrigin-RevId: 206746172
* Return Java providers only onceGravatar elenairina2018-07-30
| | | | | | | through JavaInfo, instead of returning them also through ConfiguredTarget. Since these providers can not be found in ConfiguredTarget anymore they have to be retrieved from JavaInfo instead. RELNOTES: None. PiperOrigin-RevId: 206585413
* Add manifestProtoOutput produced during Java compilation to the OutputJar so ↵Gravatar Googler2018-07-30
| | | | | | | that it can be accessed in Skylark. One example where this is used is in Android IDL processing where the manifestProtoOutput is used to split out the Android IDL generated Java classes from the overarching outputJar produced by the android_library rule. RELNOTES: none PiperOrigin-RevId: 206580880
* Expose AndroidLibraryResourceClassJarProvider to skylark.Gravatar Googler2018-07-17
| | | | | RELNOTES: None PiperOrigin-RevId: 204953629
* Refactor TemplateExpansionAction so that various strategies can be used to ↵Gravatar kush2018-06-29
| | | | | | | | | implement it. Also clarify the behavior of the expand_template API in the presence of multiple-substitutions. RELNOTES: None PiperOrigin-RevId: 202719656
* Flatten JavaCompilationAgs into JavaCompilationArgsProviderGravatar cushon2018-06-26
| | | | | | | | | Consolidate the creation of JavaCompilationArgsProviders, and avoid explicit handling of the 'direct' and 'recursive' cases in clients. Also add some higher-level methods to the builder API to support adding dependencies with dep/export/runtime_dep-like semantics. PiperOrigin-RevId: 202166383
* Clean out unused proto_library enforcement code.Gravatar tomlu2018-06-20
| | | | | | | | | | | | The corresponding flags have been flipped and there should be no code in the depot that violates these rules. * Make it completely illegal for proto_library to appear in any Java/Android rule * Delete code that uses the old migration flags. * Delete tests that check that Java/Android rules *can* depend on proto_library rules when certain flags are off. * Update tests (the error messages are now slightly different) RELNOTES: None PiperOrigin-RevId: 201384236
* Add flags to help enforce that android_local_test does not depend directly ↵Gravatar tomlu2018-05-28
| | | | | | | on a proto_library. RELNOTES: None PiperOrigin-RevId: 198304295
* Automated rollback of commit 372fbc2f016157b0331f83a20edad10d4b4cf9f7.Gravatar asteinb2018-05-25
| | | | | | | | | | | | | *** Reason for rollback *** Roll forward with fix: I was assuming that R.txt and symbols files are always set, but they can be null in some cases (especially in the old data processing pipeline). Properly handle them here. RELNOTES: none PiperOrigin-RevId: 198075743
* Automated rollback of commit 9d5c323a6e66842cfeb98462cf949dee58710fb8.Gravatar plf2018-05-25
| | | | | | | | *** Reason for rollback *** Crashes lots of targets in nightly blaze-2018.05.24-1: PiperOrigin-RevId: 198049395
* Move resource busybox actions to BusyBoxActionBuilder and AndroidDataContextGravatar asteinb2018-05-23
| | | | | | | | | | | | | | | | | | | | | | | BusyBoxActionBuilder makes much cleaner action builders while making it harder to do Bad Things (like collapsing NestedSets in analysis, or adding an artifact to one of the command line and the inputs but not both). Also: - In merging, simplify the code somewhat by removing unneeded conditionals - for example, the parsed merging action will always be built given the current code. - In the few builders where we aren't doing so already, parameter files should always be shell quoted and always be used when the OS is Windows. The BusyBox should always support the former and require the latter (although sufficiently large inputs may have masked this by triggering parameter files in Windows anyway). - In the builder for linking (within validation), no longer collapse the NestedSet of transitiveCompiledSymbols when adding them to the inputs. Using the new BusyBoxActionBuilder code, trying to do this would throw an IllegalStateException. RELNOTES: none PiperOrigin-RevId: 197728382
* Move non-resource busybox actions to BusyBoxActionBuilder and AndroidDataContextGravatar asteinb2018-05-22
| | | | | | | | | | | | | BusyBoxActionBuilder makes much cleaner action builders while making it harder to do Bad Things (like collapsing NestedSets in analysis, or adding an artifact to one of the command line and the inputs but not both). Remaining action builders will be moved in the next change. Add old manifest merger tool to AndroidDataContext. RELNOTES: none PiperOrigin-RevId: 197607155
* Pass AndroidDataContext through manifest processing methodsGravatar asteinb2018-05-22
| | | | | | | | | | | | | | | Manifest processing methods are particularly messy for this migration, since the old ApplicationManifest class is still around. Anyway, pass around AndroidDataContext instead of RuleContext everywhere we can. Note that the built-in expander does not seem able to be modified to support decoupling attributes and other information, and thus really can't be done once we get rid of RuleContext. Instead, for Skylark rules, document that expansion must happen outside of the Android data Skylark method calls (for example, for manifest_values and nocompress_extensions). RELNOTES: none PiperOrigin-RevId: 197567541
* Pass through AndroidDataContext in more placesGravatar asteinb2018-05-22
| | | | | | | | As before, actual action builders will be changed in a future CL; this just starts moving AndroidDataContext in so it's available. RELNOTES: none PiperOrigin-RevId: 197561737
* Pass AndroidDataContext through new asset and resource pipelinesGravatar asteinb2018-05-22
| | | | | | | | | | | | | | This is the first step towards using AndroidDataContext in all of Android data processing. This change does not actually modify the asset and resource processing action builders themselves - they will be migrated in an upcoming change. Also, add AndroidSemantics to some rules so they can make an AndroidDataContext. RELNOTES: none PiperOrigin-RevId: 197555938
* Expose android_binary data processing methods to SkylarkGravatar asteinb2018-05-10
| | | | | | | | | | | | Create an AndroidBinaryDataInfo to wrap binary-specific artifacts that shouldn't be exposed for libraries. This is currently only the final resource APK. Continue to extract attribute references from lower-level methods and bubble them up to the top level. RELNOTES: none PiperOrigin-RevId: 196143940
* Expose Skylark method to process android_local_test dataGravatar asteinb2018-05-09
| | | | | RELNOTES: none PiperOrigin-RevId: 196024071
* Expose process_test_data (for android_test) to SkylarkGravatar asteinb2018-05-09
| | | | | | | | Explicitly work with rele attributes at (or closer to) the top level rather than deep in the code. RELNOTES: none PiperOrigin-RevId: 196004542
* Properly rename manifestsGravatar asteinb2018-05-09
| | | | | | | | | | | | | Make AndroidSkylarkData abstract and add a getAndroidSemantics() method The Skylark stamp_manifest rule should properly use AndroidSemantics to rename the manifest as well, in keeping with the android_library rule. AndroidLocalTest should do the same manifest renaming regardless of which AndroidSemantics it is run under. Have it use a seperate method to do so. RELNOTES: none PiperOrigin-RevId: 195992300
* Fix up newly discovered bugs in decoupled Android data processingGravatar asteinb2018-05-03
| | | | | | | | | | | | | | | | | | | | | | | | - Always generate a symbols file - the new resource processing pipeline likes knowing that this is non-null, and it shouldn't cost much extra to create. - A misleading method signature (which I made) led to me forgetting about Proguard artifacts. Properly propogate them into the ResourceApk object. - Don't get Aapt version directly from AndroidConfiguration - there's some additional logic in AndroidAaptVersion not exposed elsewhere - Split library tests that expect resources and assets to be processed together to have a new version where they're processed seperately. - Tests use ValidatedAndroidData interface rather than ResourceContainer object - Properly move some LocalTest magic around resource JAR out of the old pipeline only, as it should apply to both old and new pipelines. - Processing action defaults to empty resource and asset deps rather than null RELNOTES: none PiperOrigin-RevId: 195253161
* Expose processed manifest in AndroidLocalTestGravatar asteinb2018-05-02
| | | | | | | | | | | | | Currently, resource processing does some final work on the manifest (mostly around data binding). Actually expose this manifest rather than some intermediate manifest. The manifest is already being generated, so we don't expect newly requesting it to cause any problems. And since AndroidLocalTest doesn't do data binding, the two manifests are presumably identical. RELNOTES: none PiperOrigin-RevId: 195106492
* Adding a check to verify the usage of the migration tag for the SkylarkGravatar Googler2018-04-27
| | | | | | | migration, when a flag is enabled. RELNOTES: PiperOrigin-RevId: 194630925
* Normalize parameter name commentsGravatar cushon2018-04-27
| | | | PiperOrigin-RevId: 194512971
* Add getters to JavaCompilationArgsProviderGravatar cushon2018-04-24
| | | | | | | | | | for direct, transitive, and full compile-time jars; runtime jars; and instrumentation metadata. These are trivial wrappers around the corresponding getters on the recursive and non-recursive JavaCompilationArgs objects. This is a no-op refactoring in preparation for flatting JavaCompilationArgs into JavaCompilationArgsProvider. PiperOrigin-RevId: 194047064
* Consolidate handling of jar files in depsGravatar cushon2018-04-19
| | | | PiperOrigin-RevId: 193533061
* Add deploy jar to android_local_test.Gravatar Googler2018-04-18
| | | | PiperOrigin-RevId: 193390754
* Wire up decoupled data processing for aar_import ruleGravatar asteinb2018-04-18
| | | | | RELNOTES: none PiperOrigin-RevId: 193381165
* Wire up decoupled data pipeline in top-level Android targetsGravatar asteinb2018-04-18
| | | | | | | | | | | | | | | | The decoupled pipeline is safely hidden behind a flag. I'm explicitly holding off on the MobileInstall code until next review, so we sometimes create an ApplicationManifest object even in the new pipeline to pass data to that code. I'm not thrilled with the 'just call into the resource processor with different settings' approach that I've reproduced in ProcessedAndroidData, but I don't see a better way of doing things, and I think that breaking out the commonly used settings makes things cleaner. RELNOTES: none PiperOrigin-RevId: 193373347
* Ability to stop using ResourceContainer in various actionsGravatar asteinb2018-04-18
| | | | | | | | | | | | | | | | | | | | | Now that we support decoupled asset and resource processing in the basic pipeline, we can also support it in these actions. ResourceShrinker actions, by design, does not use assets, so the change is trivial. For the AarGenerator, things get a bit more complex: - Simplify needlessly complex code around AAR generation - Move around special resource processing to generate AAR inputs in the case where there are no local resources to go next to normal resource processing - Also, clean up that code - ResourceApk wrapper class has some fields which are non-null even in the case where resources are inherited - Always pass assets and resources seperately to the AarGenerator action RELNOTES: none PiperOrigin-RevId: 193355790
* Clean up R class generationGravatar asteinb2018-04-18
| | | | | | | | | | | Remove R class generation from AndroidCommon and instead invoke it just after resource processing. This is much more intuitive, behaves the same, and will make it easier to call into R class generation on the new pipeline. Also, clean up some dead code (including newly-dead code) from AndroidCommon. RELNOTES: none PiperOrigin-RevId: 193345190
* Add decoupled asset containers to ResourceApk wrapper objectGravatar asteinb2018-04-17
| | | | | | | | | | | The ResourceApk object contains all the processed Android data. When assets are decoupled, pass them in seperately. I'll replace ResourceContainer with the ValidatedAndroidData interface as part of the next review. RELNOTES: none PiperOrigin-RevId: 193223251
* Remove legacy manifest merging from Bazel.Gravatar ajmichael2018-04-05
| | | | | RELNOTES: android_binary.manifest_merger is no longer supported. PiperOrigin-RevId: 191791177
* Remove Android jar from android_local_test bootclasspathGravatar ajmichael2018-04-02
| | | | | | | | | Instead, treat it as a regular compile-time library dependency. This fixes Java8 compilation in android_local_test. RELNOTES: None PiperOrigin-RevId: 191359834
* Rename LocalResourceContainer to AndroidResources and remove asset code from itGravatar asteinb2018-03-29
| | | | | | | | | | | | | As part of decoupling Android resources and assets, rename LocalResourceContainer to AndroidResources and remove asset code from it. Some general asset and manfiest code still remains and will be dealt with in future changes. Remove LocalResourceContainer from the ParsingActionBuilder, since it's always used to build the ResourceContainer that is subsequently passed in. RELNOTES: none PiperOrigin-RevId: 190945260
* Expose an actions provider on RuleConfiguredTarget instances.Gravatar cparsons2018-03-06
| | | | | | | | | Given a target (for example from a skylark aspect), one will be able to access a list of actions that the target generated using "target.actions". This is without additional memory footprint. Actions themselves are not fully exposed to skylark (and thus there isn't much meaning to gather from them in skylark yet). Access methods will follow soon. RELNOTES: None. PiperOrigin-RevId: 188098079
* Enable ability to pass the resource apk to Robolectric so that it can ↵Gravatar dannark2018-02-22
| | | | | | | | | consume binary resources. This functionality is guarded by a flag, --experimental_android_local_test_binary_resources whose default value is false. If the flag is set to true, Bazel will generate the .ap_ and add the path to the .ap_ to the test_config.properties file. Bazel will still generate and pass the raw resources to Robolectric in both cases and so the cue to Robolectric that binary resources should be used is the presence of the path to the .ap_ in the test_config.properties file. RELNOTES: None PiperOrigin-RevId: 186708941
* Remove unnecessary arg when building runfiles support.Gravatar ajmichael2018-01-23
| | | | | RELNOTES: None PiperOrigin-RevId: 182986489
* Add support for native header outputs to {java,android}_libraryGravatar cushon2018-01-11
| | | | PiperOrigin-RevId: 181684446
* Add android_local_test rule to Bazel.Gravatar dannark2017-12-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This rule enables testing android_librarys locally in the jvm (as opposed to on a device). To use this rule with robolectric (robolectric.org), add the following to your WORKSPACE file: http_archive( name = "bazel_android", url = "...", ) load("@bazel_android//:setup_robolectric.bzl", "setup_robolectric") setup_robolectric() and then an android_local_test rule would need to add: "@bazel_android//:robolectric", to its dependencies. android_local_test( name = "MyTest", srcs = ["MyTest.java"], deps = [ "//java/app:lib", "@bazel_android//:robolectric", ], ) RELNOTES[NEW]: New android test rule, android_local_test. PiperOrigin-RevId: 180438995
* Remove dead android_resources codeGravatar Googler2017-12-22
| | | | | RELNOTES: none PiperOrigin-RevId: 179928735
* Remove package name from license.Gravatar dannark2017-12-21
| | | | | RELNOTES: None PiperOrigin-RevId: 179838832
* Automatic formatting cleanup of Android *.java files.Gravatar jingwen2017-12-18
| | | | | RELNOTES: None. PiperOrigin-RevId: 179425421
* Rename OutputGroupProvider -> OutputGroupInfo.Gravatar dslomov2017-12-14
| | | | | RELNOTES: None PiperOrigin-RevId: 179046403
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-15 11:32:37 +0000