aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/android/ResourceShrinkerActionBuilder.java
Commit message (Collapse)AuthorAge
* Automatic formatting cleanup of Android *.java files.Gravatar jingwen2017-12-18
| | | | | RELNOTES: None. PiperOrigin-RevId: 179425421
* 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
* 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
* 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
* Migrate ResourceProcessorBusyBox Android actions to using SHELL_QUOTED param ↵Gravatar apell2017-10-18
| | | | | | | files. RELNOTES: None. PiperOrigin-RevId: 172485548
* remove unused code for unused aapt flagsGravatar ajmichael2017-09-27
| | | | | RELNOTES: None PiperOrigin-RevId: 170136145
* 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
* Enable resource shrinking for aapt2.Gravatar corysmith2017-09-12
| | | | | | | First commit in series, the second will make the necessary changes to the action. RELNOTES: None PiperOrigin-RevId: 168286654
* Inline CustomCommandLine methods that can be expressed using VectorArg.Gravatar tomlu2017-09-12
| | | | | | This whole CL was done using IDE refactoring tools and should be safe. PiperOrigin-RevId: 168275575
* Improve CustomCommandLine interface.Gravatar tomlu2017-08-22
| | | | | | | | | | | | | | | | In converting SpawnAction.Builder (multi-thousand line CL) users directly to CustomCommandLine I didn't like the resulting loss of readability, and the methods didn't feel very discoverable. Unless it's very convenient and readable to use CustomCommandLine, people will resort to non-memory efficient patterns by default. I'm holding that CL for this, which should offer a nicer interface. This CL removes VectorArg from the API contact surface area, instead creating 64 overloads for every valid combination of parameters. Pretty sad, but the methods dispatch straight to internal helper methods so it's mostly boilerplate to the tune of +400 LOC. Other changes: * Change ImmutableCollection -> Collection and copy the args directly into the internal args vector. Saves on collection object overhead and saves users from having to create immutable copies. * Change some names, notably add -> addAll for collection methods * Create additional missing overloads * Fix JavaDoc RELNOTES: None PiperOrigin-RevId: 165943879
* Add more type safety to CustomCommandLine.Gravatar tomlu2017-08-16
| | | | | | | | | | | | Allowing add(Object) is too loose and can easily lead to programmer mistakes. Because of type erasure, we can't use the same overload name for (eg.) add(NestedSet<String>) and add(NestedSet<Artifact>). The API is overhauled to use the same terms everywhere, eg. "add", "addPaths", "addExecPaths". This is similar to how it used to be a few CLs ago. The API is overhauled to make sure it's consistent for all types. While tedious, the facade methods immediately dispatch to internal helpers, so implementation wise it's not too heavy. While large, this CL is almost entirely an automated refactor. PiperOrigin-RevId: 165358287
* Add @CompileTimeConstant annotations to CustomCommandLine.Gravatar tomlu2017-08-16
| | | | | | | | | This enforces certain memory-efficient patterns. For deliberate use of dynamic strings, explicitly named overloads are introduced, with javadoc that guides the programmer into making the right choice. This CL is a memory no-op on benchmarks, but it tries to prevent backslide by making sure programmers make conscious choices when they construct their command lines. RELNOTES: None PiperOrigin-RevId: 165185997
* Inline @Deprecated methods in CustomCommandLine.Gravatar tomlu2017-08-11
| | | | | | | | | Apart from updating CustomCommandLineTest this CL is entirely automated. We also sneak in a rename of addFormat -> addFormatted. RELNOTES: None PiperOrigin-RevId: 164870140
* Improve CustomCommandLine.Gravatar tomlu2017-08-10
| | | | | | | | | | | | | Instead of having custom ArgvFragments for every combination of desired things, we make a combined "interpreter" of argvs. This saves memory and simplifies things as we do not have to allocate a strategy instance per call to args (instead pushing a single shared instance, followed by the args). The generic interpreter does have a lot of branching compared to the bespoke implementations, but because the branch is always the same for long stretches the branch predictor should easily be able to handle it with minimal overhead (~1 cycle per branch IIRC). This CL also elevates that we either want a NestedSet or an ImmutableCollection to the surface of the API, so consumers understand the cost when they call it with a non-immutable collection. Most of the changes in clients is due to this. To cut down on CL churn, @Deprecated forwarding methods are added to CustomCommandLine. These will be removed in a separate CL using IDE inlining. RELNOTES: None PiperOrigin-RevId: 164725370
* Automated rollback of commit f7f1a8f756f33f86b1bdc5023d5052117b62523e.Gravatar laszlocsomor2017-08-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Updated to avoid https://github.com/bazelbuild/bazel/issues/3501 This is a rollback of a rollback, with additional modifications to BazelConfiguration.java to fix https://github.com/bazelbuild/bazel/issues/3501, the issue that was the reason we rolled back the original change. The additional updates serve to propagate the client's TMP and TEMP envvars to the action, which is a short-term solution to allow actions have a TMP/TEMP envvar on Windows. They need at least one of those to create temp directories. The long-term solution is to set a value for TMP or TEMP in the executor just before executing the actions, so the TMP/TEMP would not be part of the action key. All of this only affects Bazel on Windows. *** Original change description *** Automated rollback of commit 0abf5fa2d64c76def5a8fa0f960b73ce0566af4d. *** Reason for rollback *** Breaks Bazel CI (https://github.com/bazelbuild/bazel/issues/3501) *** Original change description *** Android BusyBox: actions use the default shell env SpawnActions that run the Android BusyBox now use the default shell environment. This has the following benefits: - Bazel propagates the PATH, TMPDIR envvars to the action - Bazel propagates the --action_env envvars to the action This allows the Bazel client to pass --action_env=TMP or --action_env=TEMP (whichever of the envvars is defined) to the server, so the BusyBox actions will have TMP/TEMP set (to the same value as the clientenv), so they can create temp directories using java.nio.file.Files.createTempDirectory. This method seems to be calling the GetTempPath WinAPI function, which needs the TMP or TEMP envvar, otherwise it falls back to returning c:\windows which is non-writable. There's one drawback of using the default shell environment, although @ulfjack is working on it: - PATH is now also part of the action's cache key. However in a single-machine environment (no remote execution) and assuming PATH isn't likely to change between builds, this probably doesn't poision the action cache in practice. This change is a short-term solution. Propagating the client env's TMP/TEMP means we make that part of the action's cache key. The ideal long-term solution will be to not propagate this envvar, and instead let the execution strategy set it to some client-env-independent value. See https://github.com/bazelbuild/bazel/issues/3264 Change-Id: I756a4203b5d86c881bc36cc089e35cde0d419914 RELNOTES: none PiperOrigin-RevId: 164696600
* Automated rollback of commit 0abf5fa2d64c76def5a8fa0f960b73ce0566af4d.Gravatar laszlocsomor2017-08-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks Bazel CI (https://github.com/bazelbuild/bazel/issues/3501) *** Original change description *** Android BusyBox: actions use the default shell env SpawnActions that run the Android BusyBox now use the default shell environment. This has the following benefits: - Bazel propagates the PATH, TMPDIR envvars to the action - Bazel propagates the --action_env envvars to the action This allows the Bazel client to pass --action_env=TMP or --action_env=TEMP (whichever of the envvars is defined) to the server, so the BusyBox actions will have TMP/TEMP set... *** PiperOrigin-RevId: 164126020
* Android BusyBox: actions use the default shell envGravatar Laszlo Csomor2017-08-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SpawnActions that run the Android BusyBox now use the default shell environment. This has the following benefits: - Bazel propagates the PATH, TMPDIR envvars to the action - Bazel propagates the --action_env envvars to the action This allows the Bazel client to pass --action_env=TMP or --action_env=TEMP (whichever of the envvars is defined) to the server, so the BusyBox actions will have TMP/TEMP set (to the same value as the clientenv), so they can create temp directories using java.nio.file.Files.createTempDirectory. This method seems to be calling the GetTempPath WinAPI function, which needs the TMP or TEMP envvar, otherwise it falls back to returning c:\windows which is non-writable. There's one drawback of using the default shell environment, although @ulfjack is working on it: - PATH is now also part of the action's cache key. However in a single-machine environment (no remote execution) and assuming PATH isn't likely to change between builds, this probably doesn't poision the action cache in practice. This change is a short-term solution. Propagating the client env's TMP/TEMP means we make that part of the action's cache key. The ideal long-term solution will be to not propagate this envvar, and instead let the execution strategy set it to some client-env-independent value. See https://github.com/bazelbuild/bazel/issues/3264 Change-Id: I756a4203b5d86c881bc36cc089e35cde0d419914 PiperOrigin-RevId: 164114502
* 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
* Allow the aapt2 code paths to be enabled by either flag or attribute.Gravatar corysmith2017-07-21
| | | | | RELNOTES: None PiperOrigin-RevId: 162613289
* Automated rollback of commit 01ddfb7bf418b371859de62f4eab2f41ea9a4a4a.Gravatar laszlocsomor2017-07-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a partial rollback. I restored the old flags (with PathListConverter), added the new ones, added deprecation warnings and annotations, and added code to concat the values of new and old. Existing released versions of Bazel should keep working with the new code until 2018-01-31, i.e. for the next ~6 months. After that I'll remove the old flags and the PathListConverter. *** Reason for rollback *** Fixed broken integration with release Blaze. *** Original change description *** Automated rollback of commit 5752463ece84ebb4fb074888cba57412ab8d86b3. *** Reason for rollback *** Broke too many targets. *** RELNOTES: none PiperOrigin-RevId: 162587548
* Automated rollback of commit a76c94be7c56b93fc5a2f9ececfba7ac1f61f69c.Gravatar laszlocsomor2017-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Caused memory regression. *** Original change description *** CustomCommandLine.Builder: clean up its interface In this commit: - remove unused methods and classes - turn CustomCommandLine.ArgvFragment into an interface - remove the CustomCommandLine.TreeFileArtifactArgvFragment abstract class; it only had one remaining subclass - add @Nullable annotations where nulls are fine - add Precondition checks for non-nullable args - simplify the interface by removing add* methods that can be composed of other add* methods; this makes it easier to see... *** RELNOTES: none PiperOrigin-RevId: 162320031
* Internal changeGravatar Googler2017-07-17
| | | | PiperOrigin-RevId: 162194755
* AndroidBusyBox: deprecate path-list-type flagsGravatar laszlocsomor2017-07-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit: - deprecates PathListConverter - removes ExistingPathListConverter because it was not used in production, only tests - deprecated List<Path> type flags that use PathListConverter - introduces new List<Path> type flags next to the deprecated ones that use @Options.allowMultiple and convert with PathConverter; the new and old lists are concatenated, yielding the flag value PathListConverter and all of its occurrences should be removed after 2018-01-31 (about 6 months from now, which is a safe enough timeframe for everyone to upgrade Bazel so it uses the new-style flags). Reason for deprecation is that colon-separated path lists don't work on Windows because paths have colons in them. Since the Android BusyBox is not intended to be executed by users but by Bazel only, there's no release notes necessary. See https://github.com/bazelbuild/bazel/issues/3264 RELNOTES: none PiperOrigin-RevId: 162193998
* CustomCommandLine.Builder: clean up its interfaceGravatar laszlocsomor2017-07-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In this commit: - remove unused methods and classes - turn CustomCommandLine.ArgvFragment into an interface - remove the CustomCommandLine.TreeFileArtifactArgvFragment abstract class; it only had one remaining subclass - add @Nullable annotations where nulls are fine - add Precondition checks for non-nullable args - simplify the interface by removing add* methods that can be composed of other add* methods; this makes it easier to see what the callers do with the Builder - remove add* methods that add a single argument followed by a list of other elements (or a joined string of them); these had a bug in that they didn't check if the collection was empty (only that it was not null), and if it was empty then the single argument was still added though it was not followed by any value - fix call sites of add* methods where we previously could have added a flag with an empty collection - audit every affected call site RELNOTES: none PiperOrigin-RevId: 161957521
* 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 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
* Use platform-specific path separator for --dependencyManifests.Gravatar Adam Michael2017-03-14
| | | | | | | | | This is read by PathListConverter which uses java.io.File#pathSeparator which is already platform-specific. -- PiperOrigin-RevId: 150008708 MOS_MIGRATED_REVID=150008708
* 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
* Implicitly generate Proguard obfuscation mapping file for android_binary ↵Gravatar Andrew Pellegrini2017-02-24
| | | | | | | | | | targets when both resource shrinking and Proguard are enabled, as it is required by resource shrinking to work properly. RELNOTES: Automatically generate Proguard mapping when resource shrinking and Proguard are enabled. -- PiperOrigin-RevId: 148349205 MOS_MIGRATED_REVID=148349205
* Rollback of commit 602a98cbebeff2ba1c2d8605a9552b2c8f5622ae.Gravatar Googler2017-02-09
| | | | | | | | | | | | | | | | *** Reason for rollback *** Rolling forward with fixes for the incremental tool. *** Original change description *** Automated [] rollback of commit d11d510c571b10787856395709f9ad945ca70bb2. *** Reason for rollback *** -- PiperOrigin-RevId: 146940409 MOS_MIGRATED_REVID=146940409
* Rollback of commit d11d510c571b10787856395709f9ad945ca70bb2.Gravatar Alex Humesky2017-02-08
| | | | | | | | *** Reason for rollback *** -- PiperOrigin-RevId: 146820790 MOS_MIGRATED_REVID=146820790
* Move all the resource processing tools into a "busybox".Gravatar Googler2017-02-08
| | | | | | | | | This makes the code simpler as well as reducing the number of targets to build. It also makes testing and profiling different action strategies vastly easier. -- PiperOrigin-RevId: 146812659 MOS_MIGRATED_REVID=146812659
* 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
* Add target label to progress messages for some Android build actions.Gravatar Andrew Pellegrini2016-09-26
| | | | | -- MOS_MIGRATED_REVID=134118816
* Change android resource shrinking to use the standard Proguard jar artifact.Gravatar Andrew Pellegrini2016-07-27
| | | | | | | | * Re-add proguard mapping file handling to ResourceShrinker to handle the fully Proguarded code, potentially including an obfuscation step. * Update android_binary to provide the resource shrinker with the standard Proguard jar and obfuscation mapping instead of a custom built shrunk jar. -- MOS_MIGRATED_REVID=128476602
* Add output log for android resource shrinking, following the format produced ↵Gravatar Andrew Pellegrini2016-07-04
| | | | | | | by the Gradle resource shrinker in resources.txt. -- MOS_MIGRATED_REVID=126420534
* Provide ResourceShrinker with the generated R.java packages in addition to ↵Gravatar Andrew Pellegrini2016-04-08
| | | | | | | packages from manifests. This prevents resources from being removed when they have been generated into a package other than the one specified in their target's manifest. -- MOS_MIGRATED_REVID=119294591
* Adds ResourceShrinkerAction to android_binary targets if they use Proguard ↵Gravatar Andrew Pellegrini2016-03-08
and specify --experimental_android_resource_shrinking on the command line. RELNOTES: Specifying --experimental_android_resource_shrinking on the command line will enable a resource shrinking pass on android_binary targets that already use Proguard. -- MOS_MIGRATED_REVID=116572863
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 02:41:33 +0000