aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/java/com/google/devtools/build/lib/rules/android
Commit message (Collapse)AuthorAge
* Create a whitelist for android_library rules with deps but not srcsGravatar cushon2018-07-03
| | | | PiperOrigin-RevId: 203230801
* supply transitive and direct deps for aar_import deps checking. This allows ↵Gravatar kmb2018-07-03
| | | | | | | | producing add_dep commands where possible and avoids the need for direct dependencies on supertypes of directly depended types RELNOTES: None. PiperOrigin-RevId: 203164113
* Automated refactor of Label.parseAbsolute() to always pass a repository mappingGravatar dannark2018-06-27
| | | | | RELNOTES: None PiperOrigin-RevId: 202360925
* Remove LIPO supportGravatar hlopko2018-06-15
| | | | | RELNOTES: Support for LIPO has been fully removed. PiperOrigin-RevId: 200724578
* Change the default value of ↵Gravatar dannark2018-06-12
| | | | | | | | --experimental_android_local_test_binary_resources to true. RELNOTES[NEW]: android_local_test now takes advantage of Robolectric's binary resource processing which allows for faster tests. PiperOrigin-RevId: 200296572
* Automated rollback of commit 5df8eb24f84a6943e70876c805c77f06e719dcd7.Gravatar Googler2018-06-08
| | | | PiperOrigin-RevId: 199864175
* Make Artifact#equals take the owner into account for derived artifacts.Gravatar janakr2018-06-08
| | | | | | | | Derived artifacts' owners are important because they are used to determine the artifact's generating action. Source artifacts' owners are not used in this way, so I left them alone. This allows us to get rid of most uses of ArtifactSkyKey. We may be able to delete it entirely in a follow-up. PiperOrigin-RevId: 199836436
* Automated rollback of commit ccaccb2b277a82f7264567563a02ab133a0f6e6f.Gravatar jmmv2018-06-07
| | | | | | | | | | | | | | | *** Reason for rollback *** Suspected root cause behind tons of Blaze nightly failures. One example: [] *** Original change description *** Let blaze obfuscate manual main_dex_list according to proguard map. PiperOrigin-RevId: 199737371
* Let blaze obfuscate manual main_dex_list according to proguard map.Gravatar Googler2018-06-06
| | | | PiperOrigin-RevId: 199529974
* Remove STRICT_ERROR from ImportDepsCheckingLevel, as it is replaced with ERROR.Gravatar cnsun2018-06-05
| | | | | RELNOTES: None. PiperOrigin-RevId: 199382344
* Explicitly validate local resources are passed to Java compilation firstGravatar asteinb2018-05-31
| | | | | | | We thought we had a test for this, but it turns out we didn't. Add one now. RELNOTES: none PiperOrigin-RevId: 198772854
* Fix `equals()` and `hashCode()` for artifacts: artifacts of different ↵Gravatar Dmitry Lomov2018-05-30
| | | | | | | | | | | | | classes are not equal. Also validate that there are no tree and file artifacts with the same exec path. Fixes #4668. Closes #5284. Change-Id: Id97c0407a476a5bfc697b4ca7b858e3d0c0f8c75 PiperOrigin-RevId: 198540425
* Fix edge case in inferring Java package from path to targetsGravatar asteinb2018-05-29
| | | | | | | | When deriving the Java package from path to a target, actually derive it from the path to the entire target, not just the target's BUILD file. RELNOTES: none PiperOrigin-RevId: 198426047
* Use independently passed assets in aapt2 packaging as wellGravatar asteinb2018-05-29
| | | | | | | | | | | | | | Much earlier, I made a change that allowed passing assets without resources to aapt packaging. Do the same for aapt2 packaging too. The busybox seems to be expecting compiled symbols, so compile assets and pass the compiled version in. (Compiling assets doesn't save any time, but doesn't cost much either, and means that we'll eventually be able to phase out the parsed form entirely. Adapting the Busybox to take parsed assets would probably work too, but getting the code to handle it would be really messy.) RELNOTES: none PiperOrigin-RevId: 198417111
* 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
* Expose [AndroidAssetsInfo].local_assets, [AndroidAssetsInfo].local_asset_dir ↵Gravatar Googler2018-05-24
| | | | | | | and [AndroidResourcesInfo].r_txt to Skylark. RELNOTES: none PiperOrigin-RevId: 197902129
* 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
* 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
* Make ImportDepsCheckingLevel.ERROR essentially the same as STRICT_ERROR, ↵Gravatar cnsun2018-05-16
| | | | | | | checking direct dependencies. RELNOTES: None. PiperOrigin-RevId: 196860008
* Enable manual trimming of config_feature_flags.Gravatar mstaib2018-05-16
| | | | | | | This enables users of config_feature_flags to specify the flags used by the transitive closure of a particular target in the transitive_configs attribute of all targets. It also adds a flag - --enforce_transitive_configs_for_config_feature_flag - which enforces this specification and uses it to trim the set of flags available to that target. RELNOTES: None. PiperOrigin-RevId: 196846092
* 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 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
* Get resource processing settings from method params instead of rule attrsGravatar asteinb2018-05-09
| | | | | | | | | | | | | | | | In a previous review, I left some setting controlled only by rule attributes. Now actually specify them in Skylark method params. Data binding and should mimic behavior in existing android_* rules. For library, aapt_version cannot be passed in; we use the flag value. I left the SDK attribute intact as it's private. People should be setting defaults in rules but otherwise overriding SDK with flags, not parameters. This mimics existing behavior. RELNOTES: none PiperOrigin-RevId: 195970351
* Make Aar provider into NativeInfoGravatar asteinb2018-05-07
| | | | | | | This provider needs to be the new type so we can expose Aar information in Skylark RELNOTES: none PiperOrigin-RevId: 195710606
* Stop collapsing NestedSet of deps in RClassGeneratorGravatar asteinb2018-05-07
| | | | | | | This collapsing should be avoided when possible, and punted on until execution when needed. RELNOTES: none PiperOrigin-RevId: 195695290
* Emit jdeps.proto when checking the dependencies of aar_import targets.Gravatar cnsun2018-05-04
| | | | | RELNOTES: none. PiperOrigin-RevId: 195497740
* 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
* Fix tests to be compatible with deferred param files.Gravatar tomlu2018-05-02
| | | | | | | For the most part, this involves removing assertions that there are param files as inputs, and that the param file arguments appears in the arguments list. RELNOTES: None PiperOrigin-RevId: 195070407
* Normalize parameter name commentsGravatar cushon2018-04-27
| | | | PiperOrigin-RevId: 194512971
* Abstract away the param file write action from tests.Gravatar tomlu2018-04-26
| | | | | | | | | | | Rule authors frequently wants to make assertions on the parameter files their rule implementations have created. However, if they do not explicitly create parameter file write actions, or if indeed _there aren't_ any parameter file write actions inserted into the action graph, the tests will fail. This CL puts an abstraction between the tests and obtaining their parameter files, allowing us to change the implementation without updating hundreds of lines of test code in the same CL. Note that we can no longer sanely assert that the parameter file argument is inserted into the main command line, because the parameter file system controls both whether it is inserted and the name used. Those assertions have been removed where found. RELNOTES: None PiperOrigin-RevId: 194430947
* Remove JavaConstraintsProvider, allow specifying constraints when ↵Gravatar kmb2018-04-24
| | | | | | constructing JavaInfo providers instead PiperOrigin-RevId: 194123199
* 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
* Add a new "STRICT_ERROR" for the flag "--experimental_import_deps_checking" ↵Gravatar cnsun2018-04-23
| | | | | | | | | to check the direct dependencies for aar_import targets. Currently the default value of this flag is not changed. And it will be enabled in a separate cl. RELNOTES: None PiperOrigin-RevId: 193959866
* Add deploy jar to android_local_test.Gravatar Googler2018-04-18
| | | | PiperOrigin-RevId: 193390754
* Setup for wiring up decoupled data processing in top-level targetsGravatar asteinb2018-04-18
| | | | | | | | | | | | - Expose manifest merging logic from ApplicationManifest - Use it to reimplement manifest merging in new AndroidManifest class - Track merged resources zip in ResourceContainer - we shouldn't be forced to use hacks to get it - Clean up return type of ProcessedAndroidData.generateRClass - a ResourceApk is the general type used to wrap fully processed data. RELNOTES: none PiperOrigin-RevId: 193367162
* Create pipeline for monolithic data processing with decoupled classesGravatar asteinb2018-04-18
| | | | | | | | | | | The AndroidResourceProcessingAction does all of asset parsing and merging and all of resource parsing, merging, and validation except for R class generation, all in one action. Add class to wrap the intermediate output of this action. It can trigger R class generation to create a full ValidatedAndroidResources object. RELNOTES: none PiperOrigin-RevId: 193350591
* Independently merge assetsGravatar asteinb2018-04-17
| | | | | | | | | | Merges assets using the newly created action. Also, add BusyBoxActionBuilder to collect common boilerplate for spawning an action that invokes the Android busybox. RELNOTES: none PiperOrigin-RevId: 193192621
* Independently parse assetsGravatar asteinb2018-04-16
| | | | | | | This is the first step in processing assets completely seperately from resources. RELNOTES: none PiperOrigin-RevId: 193076991
* Resource processing pipeline uses interface instead of ResourceContainerGravatar asteinb2018-04-16
| | | | | | | | | This allows us to use either the new AndroidResources object and its children (which are fully decoupled from asset processing) or the old ResourceContainer. We'll actually turn on decoupled asset and resource processing in an upcoming change. We still need to create an asset-only pipeline and handle the binary case. RELNOTES: none PiperOrigin-RevId: 193047924
* Properly expose resource artifacts in MergableAndroidData interfaceGravatar asteinb2018-04-16
| | | | | | | | | | | In hindsight, I should have done this a few changes ago, but the relevant change is already submitted. We need the artifacts for use in some cases where we want to use AndroidResources and ResourceContainer interchangably during migration. RELNOTES: none PiperOrigin-RevId: 193038067
* Filter ValidatedAndroidResourcesGravatar asteinb2018-04-13
| | | | | | | | | Transitive ValidatedAndroidResource objects will, in future reviews, be used in resource processing (replacing transitive ResourceContainers). To support this, we must be able to filter these objects. RELNOTES: none PiperOrigin-RevId: 192825260
* Allow validation action to run just against resourcesGravatar asteinb2018-04-13
| | | | | | | | | | This is the last step of decoupling assets and resources for the basic android_library path, but more work still needs to be done in future changes (for additional library features like aar exporting, and for top-level targets like android_binary). RELNOTES: none PiperOrigin-RevId: 192815261
* Resource-only merge actionGravatar asteinb2018-04-13
| | | | | | | | | | | | | | | | | | | Create wrapper for merged resources, and methods to make it from parsed resources. Currently just reuse the ResourceDependencies class to provide resource dependencies; we could create an interface and another class, but this class is good enough (and will be resource-specific once we finish decoupling assets, resources, and manifests). Note that, like the previous parse action, merging sometimes has a dependency on the stamped manifest, so resources and manifests will only be mostly decoupled. Also, make the merge action not require an output manifest for cases like this. RELNOTES: none PiperOrigin-RevId: 192805891
* Add skipped manifest processing methodsGravatar asteinb2018-04-11
| | | | | | | | | | | Add some required manifest support I didn't previously implement: - Support for exports_manifest field - Get properly processed manifest from AndroidSemantics - Correctly represent the current relationship between manifest and resource processing - resource processing uses the stamped manifest. RELNOTES: none PiperOrigin-RevId: 192508962
* Remove overly optimistic decoupled manifest processingGravatar asteinb2018-04-09
| | | | | | | | | | | | | In earlier changes, I introduced an idealised manifest processing pipeline that has no relation to what's currently being used. Instead, we should start with independent manifest processing that keeps the current behavior. We can migrate to new functionality later, time permitting. Keep some methods that will be the basis for a reasonable decoupled manifest processing implementation. RELNOTES: none PiperOrigin-RevId: 192164028
* Fix issue with filtered resourcesGravatar asteinb2018-04-09
| | | | | | | | | Apparently, I was using a flawed strategy to compute the filtered resource root paths. Instead, just recalculate those roots from scratch, replicating the behavior that existed before the change that caused problems. RELNOTES: none PiperOrigin-RevId: 192152306
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-08 09:00:47 +0000