aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/android
Commit message (Collapse)AuthorAge
* Lazily construct AndroidDeployInfo proto.Gravatar tomlu2017-08-14
| | | | | RELNOTES: None PiperOrigin-RevId: 165116857
* Rename the aapt2 library to .apk, which is what aapt2 expects for static ↵Gravatar corysmith2017-08-11
| | | | | | | libraries. RELNOTES: None PiperOrigin-RevId: 164893197
* 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
* Move core test classes to lib.analysis.testGravatar ulfjack2017-08-11
| | | | | | | | These are depended upon by analysis code, so need to live in the same library as lib.analysis. Moving them here makes it possible to split the build-base library into separate libraries for analysis, execution, and rules. PiperOrigin-RevId: 164847161
* Automated rollback of commit 8adcf839c5c42defaa2fabedfb0208e4ce97ac95.Gravatar ajmichael2017-08-10
| | | | | | | *** Reason for rollback *** RELNOTES: None PiperOrigin-RevId: 164775289
* Remove exec from $testing_shbase. It is a sh_library target that we only use ↵Gravatar ajmichael2017-08-10
| | | | | | | to get googletest.sh from to put in the runfiles. RELNOTES: None PiperOrigin-RevId: 164737919
* 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
* Add flag to use processed resource apk manifest fileGravatar Googler2017-08-09
| | | | | RELNOTES: none PiperOrigin-RevId: 164646858
* Move the Skylark rule infrastructure from lib.rules to lib.analysis.skylarkGravatar ulfjack2017-08-09
| | | | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. Unfortunately, there are a number of reverse deps from analysis code to Skylark classes, so moving these is the only way to make progress. PiperOrigin-RevId: 164612957
* Windows, AndroidBusyBox: always use params filesGravatar laszlocsomor2017-08-09
| | | | | | | | | | | | | | | On Windows, Bazel will always use params files for some BusyBox tools, because some flags of these tools expect values with special characters in them. We need this change so Bazel can safely pass such flags to the BusyBox on Windows. See https://github.com/bazelbuild/bazel/issues/3264 RELNOTES: none PiperOrigin-RevId: 164582899
* Change logic of Blaze Java coverage.Gravatar elenairina2017-08-08
| | | | | | | | | | | | | | | | | | Change is needed due to the fact that java_import or other custom rules (genrules or Skylark) do not propagate coverage information. The lack of coverage data is caused by the fact that it is retrieved from compilation information and it is passed around through providers as Artifact(s) (also known as instrumentation metadata). The problem with the current implementation is that there is no way of retrieving instrumentation metadata from arbitrary jars provided by java_import or other custom rules. The instrumentation metadata in the current implementation is a separate jar that contains uninstrumented classes for offline Jacoco instrumentation. This change addresses that problem by having just one jar instead of 2 (the build jar and the instrumentation jar), adding the uninstrumented classes in the build jar and completely removing any other instrumentation metadata. Implementation details: * For each build jar there is a .txt file created that contains the relative path of each Java file. This file will also be included in the final build jar. It is used for recreating the correct path for each covered file when included in the coverage report. * java_binary/java_test will set 2 environment variables: 1) JACOCO_METADATA_JARS - replaces the previous JACOCO_METADATA_JAR that was a jar that merged all the uninstrumented classes on the classpath in one jar. The new environment variable holds the paths of the runtime classpath jars - only some of them contain uninstrumented classes, letting the Jacoco coverage runner to filter and analyze them. 2) JACOCO_MAIN_CLASS - The main class to be called for the current coverage run. Previously this information was embedded in the JACOCO_METADATA_JAR's manifest. PiperOrigin-RevId: 164562533
* Move RuleConfiguredTargetFactory to lib.analysisGravatar ulfjack2017-08-07
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164446955
* Move AliasProvider to lib.analysisGravatar ulfjack2017-08-07
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164438390
* Android BusyBox: deprecate --libraries flagGravatar laszlocsomor2017-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Deprecate the --libraries flag of the GENERATE_BINARY_R tool in favour of --library. The new flag is multi-value and uses "," as the pair-separator instead of ":". The value converter still supports ":"-separated pairs as well, but looks for "," first. Old format: --libraries=key1:value1,key2:value2,... New format: --library=key1,value1 --library=key2,value2 Motivation: - the ":"-separator prevents using absolute paths on Windows The old flag is still supported, but will be removed after 2018-02-28 (about 6 months from now). Also in this commit: - add a new method to CustomCommandLine.Builder to lazily construct the command line for the --library flag See https://github.com/bazelbuild/bazel/issues/3264 RELNOTES: none PiperOrigin-RevId: 164246506
* Use @CompileTimeConstant on SpawnAction.Builder#setProgressMessage.Gravatar tomlu2017-08-04
| | | | | | | | | Add SpawnAction.Builder#setProgressMessageNonLazy for dynamic strings. This should help guide users to the right method. This also helped find a few methods I'd missed previously that could use a constant-string version. RELNOTES: None PiperOrigin-RevId: 164150264
* 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
* Better names for declared providers-related classes.Gravatar dslomov2017-08-01
| | | | | | | | Follows https://docs.google.com/document/d/1aAIVWvHPERDz2cv_PCFGwr8dvh5FcAkENFoRsNS4clk/. RELNOTES: None. PiperOrigin-RevId: 163728291
* Use dynamically configured resource filteringGravatar Googler2017-07-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Actually hook up the resource filtering configuration transitions to AndroidConfiguration's topLevelConfigurationHook. Dynamic configuration is inefficient when multiple configurations are used. Multiple configurations result in splitting the build graph and duplicating work. To avoid using multiple configurations as much as possible, dynamically configured resource filtering will only be applied for top-level android_binary targets. When android_binary targets are included as dependencies, it's very likely that multiple binaries with many shared dependencies but different configurations would be used. Only applying dynamic filtering to top-level binaries removes this concern. It is still possible to build multiple top-level binary targets with different configurations at once. Previous versions of this code considered not using dynamic configuration in that case as well, but that raised some unanswered questions about whether Bazel's invariants should allow modifying one target's configuration based solely on targets that happen to be building in parallel. As a result, that optimization is not included for now; we assume that developers manually building multiple similar binaries at once is relatively rare (plus, dynamically configured resource filtering in general is not turned on by default and will not be turned on by default until we're confident the benefits outweigh the costs). RELNOTES: none PiperOrigin-RevId: 163464415
* Assert that declared providers are not TransitiveInfoProviders.Gravatar dslomov2017-07-28
| | | | | | | Also fix the remaining violations. RELNOTES: None. PiperOrigin-RevId: 163391215
* Define an outgoing rule transition interface.Gravatar gregce2017-07-27
| | | | | | | | | | This lets a parent choose a transition for its dep based on the dep's rule class. Implement (experimental) dynamic Android resource filtering trimming with this. PiperOrigin-RevId: 163259052
* Resource filtering should preserve all matching artifacts, despite shared namesGravatar Googler2017-07-27
| | | | | | | | | | | | | | | | | | Before this change, density-based resource filtering tracked resources by qualifiers and name. Resources with density qualifiers specified would go into this code, but only one resource would be chosen from each each (qualifier, name) pair. Instead, track the resource using its entire path, this tracking resources with the same name seperately. Also, in case multiple resource are passed to the resource processing action, resource filtering only ignores a file if its name was in the list of resources to ignore *and* it does not exist. Otherwise, legitimate resources with the same name as a filtered resource might be ignored. RELNOTES: none PiperOrigin-RevId: 163235681
* Add the android.jar to the validate and link step for aapt2.Gravatar corysmith2017-07-26
| | | | | RELNOTES: None. PiperOrigin-RevId: 163126457
* Inherit allowable resource directories from android_ide_commonGravatar Googler2017-07-26
| | | | | | | | | Currently, allowable resource directories are defined in two places: LocalResourceContainer, and android_ide_common (used, for example, by ResourceFilter). Instead, keep them defined only in android_ide_common, a more authoritative source that we already rely on anyway. RELNOTES: none PiperOrigin-RevId: 163100497
* 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
* Make $jarjar_bin point to //tools/android:jarjar_bin.Gravatar ajmichael2017-07-24
| | | | | | | Fixes TODO in AndroidRuleClasses.java. RELNOTES: None PiperOrigin-RevId: 162955052
* Distinguish mnemonics between different usages of aapt.Gravatar ajmichael2017-07-24
| | | | | RELNOTES: None PiperOrigin-RevId: 162945309
* Use ActionInputFileCache instead of MetadataHandler in more placesGravatar ulfjack2017-07-24
| | | | PiperOrigin-RevId: 162906919
* Remove --experimental_android_use_singlejar_for_multidex.Gravatar ajmichael2017-07-21
| | | | | | | | This flag has been a no-op for a while with a deprecation warning that it will be removed. RELNOTES: Remove --experimental_android_use_singlejar_for_multidex. PiperOrigin-RevId: 162643922
* Fold AndroidAaptBaseRule into AndroidBaseRule.Gravatar ajmichael2017-07-21
| | | | | | | This is a no-op, the same classes inherited from them. RELNOTES: None PiperOrigin-RevId: 162627873
* 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
* RELNOTES: Ignore --glibc in the Android transition.Gravatar Googler2017-07-19
| | | | PiperOrigin-RevId: 162408227
* Clean up ConfigFeatureFlagProvider.Gravatar mstaib2017-07-19
| | | | | | | | | | | | Restrict visibility of the Skylark constructor to the package, which is still necessary because ConfigSkylarkCommon exposes it, otherwise it would be private. It matters less now that these providers are type-safe, but it's still slightly cleaner. RELNOTES: None. PiperOrigin-RevId: 162367759
* 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
* Make the @Option annotation depend on the java version of the tagging enums.Gravatar ccalvarin2017-07-18
| | | | | | | The option filters proto dependency can be removed from the OptionsParser. This is in response to option parser users that want to avoid the bazel-internal proto file in their dependencies. RELNOTES: None. PiperOrigin-RevId: 162249778
* Dynamic transitions for controlling resource filteringGravatar Googler2017-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | Dynamically Configured Resource Filtering change 4/6 Add dynamic transitions for controlling resource filtering. These transitions will be called in the next few reviews. Specifically, one transition turns dynamically configured resource filtering on, and updates the dynamically passed resource filter to contain the current target's resource filtering settings. The other turns off dynamic filtering, including removing all filtering settings and transitioning to FilterBehavior.FILTER_IN_ANALYSIS. We apply the appropriate transition in getTopLevelPatchTransition: if dynamic filtering was not requested, no transition is made; if dynamic filtering was requested but would not be appropriate (either because multiple top-level targets would mean dynamic configuration would probably split the build graph, or because no resource filters were provided so dynamically propagating them would be a waste of time) we transition to static filtering, and, otherwise, we continue to use dynamic filtering but preserve the current target's filtering settings so they can be passed to its dependencies. These transitions will actually be called in the next review. RELNOTES: none PiperOrigin-RevId: 162209042
* Cleanup in Android/C++/Java providers documentationGravatar laurentlb2017-07-18
| | | | | RELNOTES: None. PiperOrigin-RevId: 162205838
* 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
* ResourceFilter supports dynamically configured resource filteringGravatar Googler2017-07-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dynamically Configured Resource Filtering change 3/6 Resource filtering behaves somewhat differently when dynamically configured. Resources obtained from dependencies will have already been filtered and do not need to be filtered again. Resources that were filtered out do not need to be tracked since resource processing will never receive a reference to them anyway. Also, to make builds where ResourceFilter is dynamically configured, add equals and hashCode methods (otherwise, the configuration code throws a NullPointerException) and a global output prefix (otherwise, conflicts can occur). To ensure that the global output prefix (and the ResourceFilter object itself) is the same regardless of the ordering of filters in the android_binary, build the filters into a set, not a list, and sort them as part of creating the ResourceFilter object. This way, for example, objects built with filters "en,fr", "fr,en", and "en,en,fr" will all end up equal. Finally, rename the getFilteredResources method to better reflect its new role, and improve the isPrefiltering method to not try to prefilter if there are no filters. Add tests for all of this, and helper methods for all of those tests, including, most notably, a makeResourceFilter method that instantiates a ResourceFilter similarly to how it is actually created outside of tests (rather than directly calling the constructor) and a fake implementation of AttributeMap to support this. RELNOTES: none PiperOrigin-RevId: 162099178
* 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
* 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
* Detect one version violations while building android_binary targetsGravatar Googler2017-07-14
| | | | PiperOrigin-RevId: 161910195
* Add flag to turn Android resource merge conflicts from warnings into errorsGravatar Googler2017-07-14
| | | | | RELNOTES: none PiperOrigin-RevId: 161831232
* Make native declared providers not implement TransitiveInfoCollection.Gravatar dslomov2017-07-12
| | | | | | | | | | | | (Almost) all native declared providers are accessed as such and not as native non-declared providers (inheritors of TransitiveInfoCollaction). There are still three providers that use TransitiveInfoCollection.WithLegacySkylarkName mechanism, I'll address them in the follow-up CL. RELNOTES: None. PiperOrigin-RevId: 161655315
* Moves printing method for feature accessibility errors.Gravatar plf2017-07-12
| | | | | | | | The method is moved to FeaturePolicyConfiguration.java so that it can be used by unrelated parts of the code using feature policies for whitelisting. RELNOTES:none PiperOrigin-RevId: 161648169
* Minor cleanup of AndroidConfiguration.Gravatar ajmichael2017-07-12
| | | | | RELNOTES: None PiperOrigin-RevId: 161588977
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-15 10:41:45 +0000