aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/android/ApplicationManifest.java
Commit message (Collapse)AuthorAge
* Stop filtering resources in analysis in aapt2 buildsGravatar Googler2017-12-08
| | | | | | | | aapt2 always gets the complete, unfiltered resources, and then filters them in execution. Save time by not uselessly filtering in analysis. RELNOTES: none PiperOrigin-RevId: 178397137
* Infrastructure for fixed checking if android_test can inherit resourcesGravatar Googler2017-12-08
| | | | | RELNOTES: none PiperOrigin-RevId: 178369060
* Add option to enable resource cycle shrinking.Gravatar Googler2017-11-21
| | | | | | | | This will instruct AAPT2 to produce conditional keep rules to allow for more aggressive code and resource shrinking. RELNOTES[NEW]: Add --experimental_android_resource_cycle_shrinking option to allow for more aggressive code and resource shrinking. PiperOrigin-RevId: 176530749
* Add experimental flag to skip the parsing action if using aapt2.Gravatar Googler2017-11-15
| | | | | RELNOTES: none PiperOrigin-RevId: 175866310
* Filter local and transitive resources togetherGravatar Googler2017-11-06
| | | | | | | | | | | | | | | | | | Whether a resource is accepted or rejected by density-based resource filtering is dependent on what other resources are available. When filtering resources in execution, this was taken into account - resources were filtered after merging. To replicate this behavior when filtering in analysis, we must look at both local and transitive resources before we actually filter anything. This process makes filtering with dynamic configuration extremely inefficient, since the NestedSet of transitive resources must be collapsed at each library target. We can fix this by only looking at the transitive resources at the top-level target, even when using dynamic filtering. I'm not implementing that in this change, however, since dynamic filtering is relatively low priority and this review is already pretty big. Note that some of the messiness around filtering ResourceDependencies and NestedSet<ResourceContainer> will go away once those NestedSets are removed. Also, stop filtering resources in android_test, since android_test can never specify resource filters. RELNOTES: none PiperOrigin-RevId: 174474491
* Rename ResourceFilter to ResourceFilterFactoryGravatar Googler2017-11-01
| | | | | | | | | | | In the next review, to handle issues around density filtering, ResourceFilterFactory will return another object that actually handles filtering. To ensure stuff is named properly, rename ResourceFilter to ResourceFilterFactory now so that the new class can be called ResourceFilter. This is a straightforward automated refactor, followed with some automated reformatting to make linting happy. I used the name ResourceFilterFactory, rather than the more concise ResourceFilters, as this class actually contains state (both around what filtering should currently do and about what resources were filtered out) and isn't just a helper class. RELNOTES: none PiperOrigin-RevId: 174049618
* Clean up LocalResourceContainer.BuilderGravatar Googler2017-11-01
| | | | | | | | | | | | | LocalResourceContainer.Builder is referenced a bunch of times, but most of those calls are identical. Replace them with a couple of factory methods. This lets us make the builder private. Additionally, LocalResourceContainer called attributeError() on the 'resources' attribute, even though 'resource_files' is now used most of the time instead. Now, the error is always given for the correct attribute. RELNOTES: none PiperOrigin-RevId: 174038035
* Fix resource generation in android_testGravatar Googler2017-10-24
| | | | | RELNOTES: none PiperOrigin-RevId: 173128623
* Fix changes that broke resource filtering, and document related confusionGravatar Googler2017-10-23
| | | | | | | | | | | | | | | | | | | | | | | | Recent changes: 1) Started passing all resources to processors, ignoring the filtered ResourceContainers, and 2) Started loading an unfiltered LocalResourceContainer into binary resource processing, in addition to the filtered container. Fix both of these. To fix the former, we need to split the misleadingly-named 'transitiveResourceRoots' (actually transitive resource and assets artifacts) into transitive resources and assets. Update resource filtering tests to catch bugs like these. Also, rename getters for resource containers to make clear that they are not getters for resources. Finally, document some weirdness and partially-completed migrations encountered as part of investigating these issues, and add appropriate TODOs and deprecation. RELNOTES: None PiperOrigin-RevId: 172929936
* Simplify ApplicationManifest by inlining createApk and simplifying the ↵Gravatar corysmith2017-10-16
| | | | | | | builder code. RELNOTES: None PiperOrigin-RevId: 172109520
* Make it an error to attempt to expand an attribute that does not existGravatar ulfjack2017-10-11
| | | | PiperOrigin-RevId: 171684595
* Move expansion functionality to a new classGravatar ulfjack2017-09-29
| | | | | | Progress on #2475. PiperOrigin-RevId: 170473111
* Move RuleConfiguredTarget to lib.analysis.configuredtargets.Gravatar gregce2017-09-19
| | | | | | This is a trivial change with a large file footprint. PiperOrigin-RevId: 169169864
* Support multiple command lines / params files in SpawnAction.Gravatar tomlu2017-09-15
| | | | | | This is necessary for the upcoming Skylark implementation of param files. PiperOrigin-RevId: 168744486
* Support for local_resource_files in android_testGravatar Googler2017-09-13
| | | | | RELNOTES: none PiperOrigin-RevId: 168444499
* aar_import creates res/values/empty.xml if it contains no resources.Gravatar ajmichael2017-08-29
| | | | | | | | | To do this, add a new tool that is used instead of zipper to get the resources out of the AAR. This tool creates res/values/empty.xml if there are no resources in the AAR. Also, some general cleaning of the code. RELNOTES: None PiperOrigin-RevId: 166768607
* Use CustomCommandLine directly instead of via SpawnAction.Builder.Gravatar tomlu2017-08-23
| | | | | | | | | | | | | This change forces use of CustomCommandLine.Builder, which has a richer interface for constructing memory-efficient command lines. It will also permit surveying the code base for inefficient patterns using an IDE. This change was done by hand and split using Rosie to assist with rollbacks in case of bugs. Reviewers, please pay particular attention to: * Each all to addInputArgument/addOutputArgument should come with a corresponding matching pair to SpawnAction.Builder#addInput and CustomCommandLine.Builder#addExecPath (eg.). * The commandLine must be set on the SpawnAction using SpawnAction.Builder#setCommandLine. Note that most calls to addPrefixed("arg=", val) should be more idiomatically expressed as add("arg", val), but this involves changing tests and making sure that the command line tools can accept the format. PiperOrigin-RevId: 166106104
* android_library can be used in the resources attributeGravatar Googler2017-08-16
| | | | | | | | | | | | | | | | | | | | | | This allows us to perform a more gradual migration away from the android_resources rule. Specifically, rather than move all android_resources targets and simultaneously move all resources attributes, we can now first transform all android_resources rules into android_library rules, and then afterwards migrate dependencies on those rules from resources into deps. This allows a two-part migration. The resources attribute, once allowed to take android_library targets, should continue to work exactly as before. There is one change in behavior - for this to work, android_library targets now need to build an output APK during resource processing. This APK will be removed once the resources attribute is removed. Once the migration is complete, the resources attribute will be removed completely. RELNOTES: none PiperOrigin-RevId: 165313447
* Compute progress message lazily in spawn action.Gravatar tomlu2017-08-03
| | | | | | | | | | Consumers using spawn action builder now have access to handy overloads that behind the scene do a lazy String.format. In 95% of cases progress messages are expressible as 0, 1, or 2 argument String.formats. This saves memory because the format string is constant and shared between all actions, and the captured subjects are usually live on the heap anyway (eg. labels). Skylark still computes its progress messages eagerly. If we want similar savings there I'd have to follow up with a Skylark proposal. PiperOrigin-RevId: 164068816
* Make --experimental_use_parallel_android_resource_processing a no-op.Gravatar ajmichael2017-07-26
| | | | | | | Also, a few small cleanups of some duplicate test methods. RELNOTES: None PiperOrigin-RevId: 163066349
* Allow the aapt2 code paths to be enabled by either flag or attribute.Gravatar corysmith2017-07-21
| | | | | RELNOTES: None PiperOrigin-RevId: 162613289
* Filter LocalResourceContainer and use it to get a filtered ResourceContainerGravatar Googler2017-07-17
| | | | | | | | | | | | | | | | | | | | | | | Dynamically Configured Resource Filtering change 2/6 We need to filter LocalResourceContainer for dynamically configured resource filtering - it is an input to resource parsing for android_library targets. Filter it appropriately. Once it's being filtered, use it to build a filtered ResourceContainer, rather than building an unfiltered ResourceContainer and then filtering it. This means filtering gets done sooner, saving a bit of time and work, and isn't done twice, which would just be bad. To do this, we pass an unbuilt ResourceContainer.Builder into createApk, rather than a fully built one. Move the setAssetsAndResourcesFrom and setManifest calls to that builder, called every time, into createApk so that we only call them once. Also, initialize the ResourceFilter object when it's needed, rather than pass it down from the binary or library. This makes the code a bit cleaner, plus means library targets will pick up the dynamically configured information once that exists. RELNOTES: none PiperOrigin-RevId: 162007885
* Add flag to turn Android resource merge conflicts from warnings into errorsGravatar Googler2017-07-14
| | | | | RELNOTES: none PiperOrigin-RevId: 161831232
* Enable aapt2 support in binary actions.Gravatar corysmith2017-07-03
| | | | | RELNOTES: None PiperOrigin-RevId: 160684786
* Add methods for filtering LocalResourceContainerGravatar Googler2017-07-03
| | | | | | | | | | | | | | | | | Dynamically Configured Resource Filtering change 1/6 To enable dynamically configured resource filtering, we'll need to be able to pass filtered resources into resource processing code used by android_library targets. The resource parsing action, used only in android_library targets, takes the LocalResourceContainer as an input, unlike android_binary processing code which never used it directly. Abstract the code for actually building the collection of resource roots out of the withResources method, and create an additional method for calling it from resource filtering. Also, split some common test code out of ResourceFilterTestBase to make a ResourceTestBase class for testing changes to this (and eventually, other) resource-oriented classes, and create LocalResourceContainerTest for this class in particular. RELNOTES: none PiperOrigin-RevId: 160640192
* Enable aapt2 support in library actions.Gravatar corysmith2017-06-29
| | | | | RELNOTES: None PiperOrigin-RevId: 160445869
* Refactoring the ApplicationManifest for clarity:Gravatar corysmith2017-06-29
| | | | | | | | * Split the aar, library and binary packWith calls. * Remove unused argument from the new binary and library packWith calls. RELNOTES: None PiperOrigin-RevId: 160414867
* Add deprecation warning if the "legacy" manifest merger is used, now that ↵Gravatar apell2017-05-23
| | | | | | | the default has been switched to "android". RELNOTES: The 'legacy' Android manifest merger is deprecated. Please upgrade to the 'android' manifest merger, which is the same merger used by Gradle. https://developer.android.com/studio/build/manifest-merge.html PiperOrigin-RevId: 156765307
* Extract determining which manifest merger to use (legacy v android) to a ↵Gravatar Googler2017-05-22
| | | | | | | separate method. This is so that android_local_test won't need access to the AndroidConfiguration fragment. RELNOTES: None PiperOrigin-RevId: 156740056
* Refactor all ctor callsites of PathFragment to instead call a static ↵Gravatar nharmata2017-04-05
| | | | | | | | | | | | 'create' method. This paves the way for changing PathFragment to e.g. an abstract class with multiple subclasses. This way we can split out the windows-specific stuff into one of these concrete classes, making the code more readable and also saving memory (since the shallow heap size of the NonWindowsPathFragment subclass will hopefully be smaller than that of the current PathFragment). This also lets us pursue gc churn optimizations. We can now do interning in PathFragment#create and can also get rid of unnecessary intermediate PathFragment allocations. RELNOTES: None PiperOrigin-RevId: 152145768
* Remove RuleContext from ResourceFilter stateGravatar Googler2017-03-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The RuleContext object is not available when creating dynamic configuration transitions. Removing it from ResourceFilter's state allows us to work with ResourceFilter objects while creating those transitions. If we didn't do this, we'd need to seperate the rest of ResourceFilter's state into a seperate class so that we could work with it as part of doing dynamic configurations. In the next reviews, I'll start actually creating dynamic configurations based on ResourceFilter state. Also, create a withAttrsFrom method that can be used in dynamic configuration transitions, and generally migrate methods that work with attributes from RuleContext to AttributeMap when practical. To support these changes: No longer keep the parsed lists of FolderConfiguration and Density objects as fields of the ResourceFilter, instead, write functions that get them when needed. We want to have access to a RuleContext when we initialize them to avoid errors, and we don't have one in the withAttrsFrom method which will be called as part of transitioning with dynamic configurations. We no longer have those parsed lists to represent whether the object filters during execution or analysis, so replace them with a seperate enum field for filter behavior. Include a FILTER_IN_ANALYSIS_WITH_DYNAMIC_CONFIGURATION option, even though it won't fully be used until the dynamic configuration transition is taken advantage of in the next few reviews. RELNOTES: none PiperOrigin-RevId: 151715400
* Partial rollback of commit 5e1a420f1b385382a2df5359faf3ae773aa8d61e.Gravatar Googler2017-03-31
| | | | | | | | | | *** Reason for rollback *** Breaks tests that expected previous id generation order. RELNOTES: None. PiperOrigin-RevId: 151638886
* Un-rollback and fix bugs in resource density filteringGravatar Googler2017-03-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | Rollback of commit df366408188f0451bae9b2ed079c795a4beb2e2b. In addition to undoing the rollback of my previous change, fix the bugs it introduced and add tests for those bugs. Always ignore empty filters. Empty filters are always useless or counterproductive. Before the original change, empty filters as a single item within the list of filters (e.g., ["en", ""]) were ignored, but empty filters as a portion of a string in the list (e.g., ["en,"]) were not. I can't imagine any reason people would actually want the empty filter (if it were handled correctly, it would effectively tell Bazel to just ignore every other filter the user passed in). Since it makes more sense with the new code, represent the stringified filters as a list of strings, rather than a single string of comma-seperated values. Manually trim whitespace from each token. Before the original change, the code trimmed whitespace following commas (e.g., ["en, es"] -> ["en,es"]) but not otherwise. If we're allowing whitespace in filter strings anyway, there doesn't seem to be any reason to allow it in some places but not others. -- PiperOrigin-RevId: 151128685 MOS_MIGRATED_REVID=151128685
* Rollback of commit bd40871283a54268945dcb0c47c0326645ffda18.Gravatar Googler2017-03-24
| | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Rolling forward with the correct changes to the AndroidResourceMergingAction. Tested manually. *** Original change description *** Automated [] rollback of commit a58f245a4b40c0ef961b1f30d96b16a9349711c3. *** Reason for rollback *** broke over 100k targets, in the depot, see [] *** Original change description *** Move library R generation to a separate action, ensuring the merging happens off the java critical path. -- PiperOrigin-RevId: 151087737 MOS_MIGRATED_REVID=151087737
* Rollback of commit 1e18045ed9d6ab9c945cec69286a7d8bd288a507.Gravatar Tobias Werth2017-03-23
| | | | | | -- PiperOrigin-RevId: 151000602 MOS_MIGRATED_REVID=151000602
* Filter android_binary resources by screen density in the analysis phaseGravatar Googler2017-03-22
| | | | | | | | | | | | | | In addition to filtering android_binary resources by resource_configuration_filters, we also filter by densities. Doing this in analysis rather than execution should also result in a speed-up as there's no need to copy files unwanted for actions to use. This behavior is controlled by the same object and flags that already control resource configuration filtering, simplifying the code. -- PiperOrigin-RevId: 150871620 MOS_MIGRATED_REVID=150871620
* adds feature_of and feature_after attrs to android_binary. these are ↵Gravatar Googler2017-03-21
| | | | | | | | android_binary rules whose .apk artifacts get piped through appt to support split apks -- PiperOrigin-RevId: 150701976 MOS_MIGRATED_REVID=150701976
* Rollback of commit a58f245a4b40c0ef961b1f30d96b16a9349711c3.Gravatar Tobias Werth2017-03-20
| | | | | | | | | | | | | | | *** Reason for rollback *** broke over 100k targets, in the depot, see [] *** Original change description *** Move library R generation to a separate action, ensuring the merging happens off the java critical path. -- PiperOrigin-RevId: 150602545 MOS_MIGRATED_REVID=150602545
* Move library R generation to a separate action, ensuring the merging happensGravatar Googler2017-03-20
| | | | | | | | off the java critical path. -- PiperOrigin-RevId: 150460041 MOS_MIGRATED_REVID=150460041
* Filter android_binary resources during analysisGravatar Googler2017-02-24
| | | | | | | | | | | | | | | | | | | | | | Before this change, resource_configuration_filters were only used to filter resources out of android_binary targets during resource processing. Instead, we can filter these unwanted resources out during analysis. This means we won't have to copy these resources for use in execution, and that execution itself will have a smaller set of inputs. This should produce a speed-up in android_binary targets with resource_configuration_filters. Also add a flag that controls this behavior. Currently, the flag defaults to not doing this prefiltering. We'll change that after further testing. Also, do some related cleanup: - Replace repeated used of the constant "resource_configuration_filters" with references to the new class - Pass around instances of the new class rather that List<String> objects meant to represent ResourceConfigurationFilters -- PiperOrigin-RevId: 148353501 MOS_MIGRATED_REVID=148353501
* Make Android data binding work with ↵Gravatar Greg Estren2017-02-17
| | | | | | | | | | | | | | | | | | | | | --experimental_use_parallel_android_resource_processing. Without that flag, data binding already works via hooks in ApplicationManifest and AndroidResourceProcessingAction. The flag replaces AndroidResourceProcessingAction with three smaller processors: AndroidResourceParsingAction, AndroidResourceMergingAction, and AndroidResourceValidatorAction. So this change hooks the same logic into AndroidResourceMergingAction (at the equivalent place where data binding applies in the other pipeline). We could alternatively hook this into AndroidResourceValidatorAction (i.e. anywhere after resource merging completes and before aapt starts). But doing that would block Java compilation on aapt finishing, which the whole point of the flag is to unblock. -- PiperOrigin-RevId: 147770236 MOS_MIGRATED_REVID=147770236
* Add getImplicitOutputArtifact to BuildViewTestCase. This vastly simplifiesGravatar Googler2017-01-23
| | | | | | | | finding actions based on intermediate artifacts. -- PiperOrigin-RevId: 145303065 MOS_MIGRATED_REVID=145303065
* Rename symbolsTxt to symbols reflecting it's actual usage.Gravatar Googler2017-01-18
| | | | | | -- PiperOrigin-RevId: 144741831 MOS_MIGRATED_REVID=144741831
* Refactor ResourceContainer: make top level and use AutoValue Builder support.Gravatar Michael Staib2017-01-04
| | | | | | | | | | | | | | | | This merges the AndroidResourceContainerBuilder (which it's not even clear is related to the nested ResourceContainer!) into the newly generated ResourceContainer.Builder. It also seemed ridiculous for ResourceContainer to get so large and still be subordinate to AndroidResourcesProvider, especially when it's getting passed around in a lot of other places (look how many imports needed fixing!). This CL makes it its own top level class. This allows for easy modification of an existing instance: call toBuilder on it, set the properties you want set, and then call build. -- PiperOrigin-RevId: 143574468 MOS_MIGRATED_REVID=143574468
* Update call sites to FileWriteAction to use the ↵Gravatar Jon Brandvein2016-12-20
| | | | | | | | | | --experimental_transparent_compression flag Also add test to ensure lazy strings aren't forced. -- PiperOrigin-RevId: 142496520 MOS_MIGRATED_REVID=142496520
* Adds internal data binding support to Bazel, although thisGravatar Greg Estren2016-11-21
| | | | | | | | | | | | | | | | | | | | | | is not yet exposed at the user level. (https://developer.android.com/topic/libraries/data-binding/index.html). See comments in DataBinding.java for the high-level overview of how this works. This does not yet work with --experimental_use_parallel_android_resource_processing. Exposing this at the user level additionally requires: 1) making the data binding support libraries available at an expected place in the depot 2) Opting in android_binary / android_library rules through a new "enable_data_binding" attribute. -- MOS_MIGRATED_REVID=139797558
* aar_import exports AndroidManifest.xml by default.Gravatar Adam Michael2016-11-07
| | | | | | | | | This was an oversight on my part in the original implementation. As one example, the Firebase AAR libraries contain AndroidManifest.xml's with ${applicationId} and Google Play Services contain <meta-data> tags. -- MOS_MIGRATED_REVID=138198047
* Add manifest merger output log.Gravatar Andrew Pellegrini2016-09-26
| | | | | | | RELNOTES: When using android_binary.manifest_merger="android" the merger produces a summary log next to the merged manifest artifact. -- MOS_MIGRATED_REVID=134082985
* Make aar_import use the java package from the manifest for all aapt resource ↵Gravatar Adam Michael2016-09-22
| | | | | | | | | rules. The AndroidResourcesProcessorBuilder, AndroidResourceValidatorActionBuilder and AndroidResourceMergingActionBuilder that use the java package specified by the AndroidResourceProvider check if it is not null or empty before using it and default to using the package from the manifest. This CL just allows us to pass null java package from AndroidSdkProvider and does so with aar_import. -- MOS_MIGRATED_REVID=133883286
* Adds aar_import rule to Bazel along with tools needed to implement it. ↵Gravatar Adam Michael2016-09-14
| | | | | | | | | | | | | | | Currently only uses AndroidManifest.xml, classes.jar and res/ from AARs. This is sufficient for many of the AARs of Google Play Services and Android Support Repository. The next step will be for AndroidSdkRepositoryRule to scan the SDK and generate aar_import rules for the AARs within. The rule is not yet documented because it is not intended for end users to use it yet. We should probably support more of the features of AARs before that time. See http://tools.android.com/tech-docs/new-build-system/aar-format for all of the files that can be included in AARs. Also note that R.txt from the AAR is intentionally ignored and regenerated based on the contents of res/. This is more correct, because the R.txt inside of an AAR can contain ids for dependencies of the AAR that are not included in res/. See https://github.com/bazelbuild/bazel/issues/564 for discussion of supporting AARs and https://github.com/bazelbuild/bazel/issues/1745 for motivation to get it done soon. -- MOS_MIGRATED_REVID=133127933
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-13 12:44:25 +0000