aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/android
Commit message (Collapse)AuthorAge
* 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
* Make some Android things more serializable.Gravatar janakr2018-06-19
| | | | PiperOrigin-RevId: 201228699
* Make java_toolchain attribute Environment aware.Gravatar dbabkin2018-06-18
| | | | | RELNOTES:none: PiperOrigin-RevId: 200988244
* Don't propagate empty asset containersGravatar asteinb2018-06-15
| | | | | | | If asset containers are empty, simply discard them rather than propagating them up the dependency graph. We don't currently use merging output except at the top level, so we don't need any of this information. (If/when asset merging is redone, we'd need to redo this code anyway.) RELNOTES: none PiperOrigin-RevId: 200721055
* SerializationCheckingGraph checks all ConfiguredTargetValues.Gravatar cpeyser2018-06-14
| | | | PiperOrigin-RevId: 200593618
* Serialize lambdas when they are cast to Serializable.Gravatar janakr2018-06-13
| | | | | | We could conceivably do some monkey-patching at server startup to make all lambdas act Serializable, but one step at a time. PiperOrigin-RevId: 200509321
* @AutoCodec stray usage of AndroidDataConverter. It should always be a static ↵Gravatar janakr2018-06-13
| | | | | | | | | | constant. This allows us to continue using lambdas in its definition. This is a partial rollback of https://github.com/bazelbuild/bazel/commit/ed1e7594b23100f89755491f36e46886b4a51c8d, since the work done to class-ify things there is unnecessary once every instance is @AutoCodec-ed. PiperOrigin-RevId: 200504678
* Reconvert the lambdas in AndroidDataConverter to anonymous inner classes.Gravatar mjhalupka2018-06-13
| | | | | | | Tag some static members with @AutoCodec. Replace some lambdas with explicit functions or classes. PiperOrigin-RevId: 200467500
* 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
* Migrate android providers to use BuiltinProvider instead of NativeProviderGravatar cparsons2018-06-11
| | | | | RELNOTES: None. PiperOrigin-RevId: 200096226
* Automated rollback of commit 5df8eb24f84a6943e70876c805c77f06e719dcd7.Gravatar Googler2018-06-08
| | | | PiperOrigin-RevId: 199864175
* 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 the $(ANDROID_CPU) Make variable.Gravatar lberki2018-06-04
| | | | | | RELNOTES[INC]: The $(ANDROID_CPU) Make variable is not available anymore. Use $(TARGET_CPU) after an Android configuration transition instead. PiperOrigin-RevId: 199241622
* Automated rollback of commit a8a8e7a0e979a8e4cf14c32471ad349a1b7d47cc.Gravatar eaftan2018-06-04
| | | | | | | | | | | | *** Reason for rollback *** Discovered bug b/109675979 with feature, and flag flip may need to be reverted *** Original change description *** Remove support for --experimental_one_version_enforcement_use_transitive_jars_for_binary_under_test PiperOrigin-RevId: 199223781
* Remove --glibc optionGravatar rosica2018-06-04
| | | | | | | Crosstool selection will be based solely on --cpu and --compiler options. RELNOTES: Option --glibc is removed, toolchain selection relies solely on --cpu and --compiler options. PiperOrigin-RevId: 199156131
* Remove the Blaze strict java deps exemption for Android databinding. As ofGravatar Googler2018-05-31
| | | | | | | | | | | | | unknown commit, we are using 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. Step 2 of 2; we needed the change to roll out in JavaBuilder first to be able to fix up issues in the depot first before removing the exemption in Blaze. See https://github.com/bazelbuild/bazel/commit/7edc5d49c8e764ab2bdf19e3a9fb58ea30fa708f for the original attempt. PiperOrigin-RevId: 198793976
* Migrate remaining Android Skylark API to skylarkbuildapiGravatar asteinb2018-05-31
| | | | | | | | I don't know much about most of this code, but there should be no functional changes. RELNOTES: none PiperOrigin-RevId: 198773657
* Remove support for ↵Gravatar cushon2018-05-30
| | | | | | --experimental_one_version_enforcement_use_transitive_jars_for_binary_under_test PiperOrigin-RevId: 198601057
* Allow rules that provide resources and assets as deps of android_* rulesGravatar asteinb2018-05-30
| | | | | | | | | | | | | | | | | | | These restrictions were originally put in place to prevent things like android_binary from being used as dependencies of android_library. However, it doesn't actually work - the restrictions are all ORed together, and that means rules that are of the allowed kind OR that have a JavaProvider are allowed. Since all android_binary targets presumably have Java providers, they are presumably all allowed. Slightly expand these restrictions by also allowing rules that have Android resource and asset providers. This will allow us to use Skylark rules to only inherit assets and resources from a target, but not anything else. I don't anticipate this expansion will have unwanted side effects, since virtually all Android targets already have Java providers anyway. RELNOTES: none PiperOrigin-RevId: 198593996
* Rename r_txt from AndroidResourcesInfo to compiletime_r_txtGravatar asteinb2018-05-29
| | | | | | | | | | I didn't catch it at the time this field was initially introduced, but R files from Android libraries, exposed via AndroidResourcesInfo, are compiletime only. They should not be used at runtime or inherited from dependencies. Rename the field and add this warning to the description. RELNOTES: none PiperOrigin-RevId: 198448391
* Expose Android data processing API in skylarkbuildapiGravatar asteinb2018-05-29
| | | | | | | | | | | | | | | | Expose the Android data processing API to skylarkbuildapi Rather than pass the SkylarkBuildApi interfaces (e.g., FileApi instead of Artifact) all the way through the Android data processing code, instead just cast them to the correct Bazel types. This is ugly, but is probably better than having to do multiple refactorings of the Android code. (A similar refactoring, for just a single type, took about 10 changes and 3300 lines of code.) The Skylark Build API is only meant for things exposed to Skylark, not Bazel internals, and, besides, when building with Bazel we should only expect inputs from other parts of Bazel. RELNOTES: none PiperOrigin-RevId: 198438519
* 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
* Properly expose asset provider for targets without explicit manifestGravatar asteinb2018-05-29
| | | | | RELNOTES: none PiperOrigin-RevId: 198402335
* Move Android data info classes to skylarkbuildapiGravatar asteinb2018-05-29
| | | | | | | | | | Expose all Android data info classes as interfaces in skylarkbuildapi. Most methods are not exposed in the interface since they are not exposed in Skylark. In fact, stop exposing a few methods from AndroidResourcesInfo that are exposed but shouldn't be. RELNOTES: none PiperOrigin-RevId: 198396677
* 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
* Remove attribute read checks expecting a DATA transition.Gravatar gregce2018-05-25
| | | | | | | | | | | | | | This is a precursor to removing the DATA transition outright. While we could also have changed the Mode.DATA instances to Mode.TARGET (which would declare that we expect the attribute not to apply any transition), that would break existing definitions and make depot cleanup more delicate. Plus, these checks weren't being consistently applied across attributes anyway so they don't really offer much. A lot of this logic is really just leftover legacy from the pre-dynamic configuration days. PiperOrigin-RevId: 198085059
* Automated rollback of commit fd260c56b46fbf68a07b29b0fc1b8cdecc4fe854.Gravatar asteinb2018-05-25
| | | | | | | | | *** Reason for rollback *** Roll forward after fixing and rolling forward culprit CL. No changes besides rolling forward (masked by diffbase) RELNOTES: none PiperOrigin-RevId: 198084160
* 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
* Automated rollback of commit 14c6d8edadb474cb72f5307b531a2699770f02d0.Gravatar plf2018-05-25
| | | | | | | | *** Reason for rollback *** Crashes lots of targets in nightly blaze-2018.05.24-1: PiperOrigin-RevId: 198041861
* Migrate OutputGroupInfo to skylarkbuildapiGravatar cparsons2018-05-24
| | | | | RELNOTES: None. PiperOrigin-RevId: 197949354
* Expose [AndroidAssetsInfo].local_assets, [AndroidAssetsInfo].local_asset_dir ↵Gravatar Googler2018-05-24
| | | | | | | and [AndroidResourcesInfo].r_txt to Skylark. RELNOTES: none PiperOrigin-RevId: 197902129
* Simplify split transition semantics: noops now return the input build options.Gravatar gregce2018-05-23
| | | | | | This results in less special logic in the implementation and a simpler API. PiperOrigin-RevId: 197772283
* Stop passing RuleContext to all of the Android Data Skylark APIGravatar asteinb2018-05-23
| | | | | RELNOTES: none PiperOrigin-RevId: 197735344
* 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
* Migrate JavaInfo's provider to use the new provider pattern.Gravatar cparsons2018-05-22
| | | | | | | This dramatically improves documentation generation for JavaInfo and it makes it far more maintainable and extensible going forward. RELNOTES: None. PiperOrigin-RevId: 197619040
* 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
* Add additional methods to BusyBoxActionBuilderGravatar asteinb2018-05-22
| | | | | | | | | | | | | Many of the Busybox action building classes rely heavily on RuleContext. While we're migrating them to AndroidDataContext, we may as well also move them to use the BusyBoxAxtionBuilder, which removes a lot of boilerplate and makes bad practices (like collapsing NestedSets) harder to do by accident. The BusyBoxActionBuilder needs some more methods to cover all the behavior seen in various action builders, so update it in one change now rather than scattering these changes across many different reviews. RELNOTES: none PiperOrigin-RevId: 197584157
* Pass AndroidDataContext to remaining non-ActionBuilder codeGravatar asteinb2018-05-22
| | | | | | | | | | | | Now that the AndroidDataContext is passed everywhere, we can begin modifying action builders. This includes removing Label information from Proguard artifact paths. getUniqueDirectoryArtifact() already included label earlier in the path, so this information was redundant anyway. RELNOTES: none PiperOrigin-RevId: 197576210
* 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
* Create AndroidDataContext to wrap context needed when working with Android dataGravatar asteinb2018-05-22
| | | | | | | | | | | | | | | | | | | This new object wraps Label, ActionConstructionContext, and various data-related tools (currently, just the resource Busybox and the Android SDK). All three of these things are required for creating pretty much any action for working with Android assets, resources, and manifests, so it makes sense to pass them around together. Eventually, we'll use this class instead of RuleContext in any code called from the Skylark APIs. For now, though, just have it wrap a RuleContext - the migration away from that will happen in future changes. Change the current Skylark API to take this class, rather than a SkylarkRuleContext. This is the first step towards not passing RuleContext (or SkylarkRuleContext) into the Skylark API. RELNOTES: none PiperOrigin-RevId: 197549155
* Make SymlinkTreeAction properly use the configuration's environmentGravatar ulfjack2018-05-22
| | | | | | | | In particular, fix its use of client make variables. Fixes #4750. PiperOrigin-RevId: 197545415
* Make ImportDepsCheckingLevel.ERROR essentially the same as STRICT_ERROR, ↵Gravatar cnsun2018-05-16
| | | | | | | checking direct dependencies. RELNOTES: None. PiperOrigin-RevId: 196860008
* Expose local_proguard_specs to Skylark.Gravatar Googler2018-05-16
| | | | | RELNOTES: none PiperOrigin-RevId: 196824775
* Replace --experimental_android_enforce_strict_deps_for_binaries_under_test ↵Gravatar cushon2018-05-15
| | | | | | with a package whitelist PiperOrigin-RevId: 196688645
* C++: Deletes CcLinkParamsInfoGravatar plf2018-05-15
| | | | | | | | This class is not necessary anymore. We can use CcLinkParamsStoreImpl directly which has been renamed to CcLinkParamsStore. RELNOTES:none PiperOrigin-RevId: 196656488
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 06:54:52 +0000