aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/android
Commit message (Collapse)AuthorAge
* 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
* Preemptively propagate DexArchiveAspect to skylark _toolchain attributesGravatar kmb2018-04-27
| | | | | | This allows incremental dexing to work with any Skylark rules that have implicit runtime dependencies. Rules should define a _toolchain attribute pointing to a Skylark toolchain. The toolchain should list all implicit runtime dependencies in a "runtime" attribute. PiperOrigin-RevId: 194611124
* Normalize parameter name commentsGravatar cushon2018-04-27
| | | | PiperOrigin-RevId: 194512971
* Make mobile-install shard for extra .dex file produced with ↵Gravatar kmb2018-04-26
| | | | | | --experimental_desugar_java8_libs PiperOrigin-RevId: 194462758
* Automated rollback of commit c5c6ef83936cf90fd11038a84637e691beb47288.Gravatar tomlu2018-04-26
| | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** b/78577719 *** Original change description *** Change action construction to use built-in param file support. We want to be able to control how and when param files are used, and manual construction of param files prevents this. It should also be less code overall. For this CL, when param files are used is unchanged, their format and encoding is unchanged. The flag name is also unchanged, except in some cases it was changed from (eg.) "--flagfile foo" to "--flagfile=foo". However, the name of the param file is now derived from the primary... *** RELNOTES: None PiperOrigin-RevId: 194389749
* Make java_common.compile's javacopt handling consistent with native Java rulesGravatar cushon2018-04-25
| | | | | | | | | | | Compilations performed by java_common.compile now use the javacopts in the java_toolchain by default, instead of requiring them to be explicitly retrived using java_common.default_javac_opts, for consistency with the native rules. java_common.compile(javac_opts=...) can still be used to pass additional javacopts. RELNOTES: Make java_common.compile now uses java_toolchain javacopts by default; explicitly retrieving them using java_common.default_javac_opts is unnecessary. PiperOrigin-RevId: 194254098
* Remove no-op check from AndroidCommon, add missing rule validation to aar_importGravatar kmb2018-04-24
| | | | PiperOrigin-RevId: 194191933
* Pass environment to Skylark provider constructors.Gravatar tomlu2018-04-24
| | | | | | | This is needed for constructors that want to be able to use SkylarkSemantics. RELNOTES: None PiperOrigin-RevId: 194180124
* Change action construction to use built-in param file support.Gravatar tomlu2018-04-24
| | | | | | | | | | | We want to be able to control how and when param files are used, and manual construction of param files prevents this. It should also be less code overall. For this CL, when param files are used is unchanged, their format and encoding is unchanged. The flag name is also unchanged, except in some cases it was changed from (eg.) "--flagfile foo" to "--flagfile=foo". However, the name of the param file is now derived from the primary output of the action (instead of manually controlled). RELNOTES: None PiperOrigin-RevId: 194171911
* Use JavaRuleOutputJarsProvider to collect non-transitive runtime jarsGravatar cushon2018-04-24
| | | | PiperOrigin-RevId: 194170571
* Automated rollback of commit 77777d1a769e938839b82c65ff320e09b1e7a715.Gravatar Googler2018-04-24
| | | | | | | | | | | | | | | | | | This CL includes the rollback + better fix for issue #4922. https://github.com/bazelbuild/bazel/issues/4922 *** Reason for rollback *** Breaks mobile-install v2 adb port forwarding, b/78432638 *** Original change description *** Fix crash from mobile-install with --device but no --adb_args. Fixes #4922. RELNOTES: None PiperOrigin-RevId: 194155557
* Fix runtime jar collection for legacy mobile-installGravatar cushon2018-04-24
| | | | PiperOrigin-RevId: 194151342
* Make some runtime jar collection non-transitiveGravatar cushon2018-04-24
| | | | PiperOrigin-RevId: 194138150
* 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
* aar_import doesn't export AndroidSkylarkApiProviderGravatar asteinb2018-04-20
| | | | | | | | aar_import probably should give IDEs the same information as other rules, but it doesn't at the moment. Stop exporting the corresponding provider. RELNOTES: none PiperOrigin-RevId: 193701950
* Fix asset processing bugGravatar asteinb2018-04-20
| | | | | | | | | | We need to pass primary asset and resource artifacts to processing, not just resources. This was introduced as part of my recent migration. In my defense, this migration was needed exactly to avoid situations like this (ResourceContainer.getArtifacts does not just return resource artifacts like you might expect it to). RELNOTES: none PiperOrigin-RevId: 193693868
* Fix error message for proguard_apply_dictionary.Gravatar Googler2018-04-19
| | | | | RELNOTES: Fixed error message for proguard_apply_dictionary. PiperOrigin-RevId: 193538106
* Consolidate handling of jar files in depsGravatar cushon2018-04-19
| | | | PiperOrigin-RevId: 193533061
* Add a flag to enable strict deps for android_binary.binary_under_testGravatar cushon2018-04-18
| | | | PiperOrigin-RevId: 193429470
* Makes ApkActionsBuilder honor --nobuild_runfile_manifests.Gravatar shahan2018-04-18
| | | | PiperOrigin-RevId: 193422658
* Wire up decoupled resource processing for MobileInstallGravatar asteinb2018-04-18
| | | | | | | | | | | | | | This should be the last place the new data processing is needed. MobileInstall is a bit trickier than normal data processing because it's out of the way. I'm still using ApplicationManifest to wrap the manifest Artifact in a lot of it, just because that makes more sense than passing around both ApplicationManifest for use with old behavior and StampedAndroidManifest for use with the new. Once we switch to entirely the new behavior, we can remove ApplicationManifest entirely. RELNOTES: none PiperOrigin-RevId: 193392923
* 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
* 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
* Clean up IterablesChain.Gravatar tomlu2018-04-18
| | | | | | | | | | | * Change builder return type to Iterable<T> instead of IterableChain<T>. It is over-specified and unnecessary to state the return type so precisely. * Optimize builder for cases where we add 0 or 1 iterables to the chain. In this case, we can simply return the underlying iterables without adding wrappers. * Extract DedupingIterable, it doesn't have anything to do with IterablesChain and is only used in one place RELNOTES: None PiperOrigin-RevId: 193363048
* Wire up decoupled data pipeline in android_libraryGravatar asteinb2018-04-18
| | | | | | | | | | | | The decoupled pipeline is safely hidden behind a flag. Since we temporarily have two different pipelines, this temporarily make AndroidLibrary messier, but it will end up much cleaner once the old pipeline is removed. The new pipeline should not be turned on until other Android rules are updated to support it (next few changes). RELNOTES: none PiperOrigin-RevId: 193361608
* 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
* 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
* 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
* Ability to pass decoupled assets into monolithic resource processing actionGravatar asteinb2018-04-17
| | | | | | | | | - New flags to pass in asset deps - Pass assets into merging in the monolithic action - Field for asset deps in asset builder action RELNOTES: none PiperOrigin-RevId: 193211038
* 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
* Provider and dependency container for Android assetsGravatar asteinb2018-04-16
| | | | | | | | | | | | These classes will allow a reasonable asset-only merging action in the next change. The relationship between AndroidAssetsInfo and AssetDependencies is a bit messy; I based it on the existing resource provider and dependencies class rather than come up with something radically different. RELNOTES: none PiperOrigin-RevId: 193085304
* 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
* Remove vestiges of support for 'reduced runtime classpaths'Gravatar cushon2018-04-14
| | | | PiperOrigin-RevId: 192914109
* 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
* Remove value equality check for proguardingGravatar asteinb2018-04-13
| | | | | | | | | ErrorProne has been complaining about this for a while, and unless there's something incredibly clever going on that I'm missing (in which case we should document it), using equals() should be just as effective. RELNOTES: none PiperOrigin-RevId: 192809127
* 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
* Automated rollback of commit 7edc5d49c8e764ab2bdf19e3a9fb58ea30fa708f.Gravatar dbabkin2018-04-13
| | | | | | | | | | | | *** Reason for rollback *** b/77997997 *** Original change description *** Remove the Blaze strict java deps exemption for Android databinding. Use the JavaBuilder processor exemption list instead of disabling strict deps for the affected rules outright. This narrows the degree to which the exemption is applied, and prevents other strict deps violations from accruing on targets that enable databinding. PiperOrigin-RevId: 192755946
* Remove JavaRuntimeJarProvider.Gravatar elenairina2018-04-13
| | | | PiperOrigin-RevId: 192736049
* Make resource merging action builder able to take just resourcesGravatar asteinb2018-04-12
| | | | | | | | | | | | In the next review, this will be used to merge resources (without assets) To support this, we need to pass around a stamped manifest with the parsed resources (since manifests cannot be decoupled fully from resource processing - aar_import means that stamped manifests are the only guaranteed way to get package information). RELNOTES: none PiperOrigin-RevId: 192649272
* 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 the Blaze strict java deps exemption for Android databinding. Use the ↵Gravatar Googler2018-04-09
| | | | | | JavaBuilder processor exemption list instead of disabling strict deps for the affected rules outright. This narrows the degree to which the exemption is applied, and prevents other strict deps violations from accruing on targets that enable databinding. PiperOrigin-RevId: 192176621
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-16 10:33:00 +0000