nit: Add a function level description like HardwareModelName() has.

You should be able to use SplitStringPiece() to get std::vector<std::string_view> avoid copies.

How about structuring this as:

```
if (allowlist.empty()) {
  // check blocklist
} else {
  // check allowlist
}
```

`std::ranges::contains(allowlist, soc)` is cleaner.

Maybe all of this can go in `IsAdpfEnabled()` helper in viz/common/features? That would be similar to the other feature block listing code like for [vulkan](https://source.chromium.org/chromium/chromium/src/+/main:gpu/config/gpu_finch_features.cc;l=424-476;drc=11a0f1ec382c206d39bd7d5cd59f5a087a69bd7c) and avoid having to export the base::FeatureParams. Alternatively a helper function in this file would be good just to separate this logic (especially when it inevitably grows at some point in the future)

WDYT about making this just kAdpf with the params below? So enabling the feature enables ADPF (optionally with the blocklist/allowlist filters), and disabling it turns it off.

We can discuss if enabling or disabling ADPF by default is the right strategy though ;)

Done

I don't mind calling it `kAdpf` - I've changed the name and the behavior when the feature is disabled.

I think it has to be enabled by default, and having neither an allowlist nor a blocklist has to imply enabled ADPF - otherwise we're going to change the default Chrome behavior on all devices for the next release (unless we time the server side config changes right, but this is too risky and I'd rather not do this).

Done

Now that this logic is in a helper function I've changed it to:
```
if (allowlist.empty()) {
  return X;
}
return Y;
```

This doesn't compile - `error: no member named 'contains' in namespace 'std::ranges'` (I have added the right header). Given that I don't see any examples of this in chromium I presume that it needs a newer compiler.

`base::Contains` works, so I've used it instead.

I've create a local helper - PTAL.

Let's put a comment here that this is about SoC makes (rather than models).

How about we make this "Google" by default? That way we don't change the behavior for Pixels but are reverting to rollout-per-SoC manufacturer for now, which seems safer than what we do today.

Yes it's a breaking change, but it feels like we should test it out elsewhere first and then explicitly decide to roll it to those SoC makes, given the regressions and issues we know of with other SoC makes so far. WDYT?

There's a sentence "if the device's SOC manufacturer satisifes the allowlist and blocklist rules". I think this is enough to tell that this about makes rather then models?

I've changed it to "Google".

As discussed in the other comment thread - making the "adpf_soc_allowlist" default value "Google" should be fine.

lgtm

Acknowledged

Yes my mistake, base::Contains() is the right thing to use now. std::ranges::contains() is C++23.

Looks good to me.

Totally optional but these could also go in `IsAdpfEnabled()` if the helper was named that.