Create a field trial for Seccomp-BPF on Android.

content/public/common/sandbox_init.h

Index: content/public/common/sandbox_init.h
diff --git a/content/public/common/sandbox_init.h b/content/public/common/sandbox_init.h
index 1a312339ee8e58013604c64283055cdcbe102edb..c8389e8db64398451182a300bedfef5735f3d2e8 100644
--- a/content/public/common/sandbox_init.h
+++ b/content/public/common/sandbox_init.h
@@ -13,6 +13,10 @@
 #include "build/build_config.h"
 #include "content/common/content_export.h"
 
+#if defined(OS_ANDROID)
+#include "base/feature_list.h"
+#endif
+
 namespace base {
 class CommandLine;
 class FilePath;
@@ -113,6 +117,11 @@ CONTENT_EXPORT scoped_ptr<sandbox::bpf_dsl::Policy>
 GetBPFSandboxBaselinePolicy();
 #endif  // defined(OS_LINUX) || defined(OS_NACL_NONSFI)
 
+#if defined(OS_ANDROID)
+// FeatureList definition for the Seccomp field trial.
+CONTENT_EXPORT extern const base::Feature kSeccompSandboxAndroidFeature;

[jam, 2015/11/13 17:20:17]

hmm, as we convert switches to base::Feature, seems like they should go into the
switches file still? i.e. otherwise where will we end up putting all the various
switches? (also seems we want them in one place like switches)

[Alexei Svitkine (slow), 2015/11/13 17:33:02]

I am okay with a centralized place for features at each layer (e.g. content/,
chrome/), although some may live in components and therefore may need to be
decentralized. (The base API allows either.)

One idea is to add a new file - e.g. content_features.cc/h similar to
content_switches and same for chrome/. Or do you prefer re-using
content_switches? WDYT?

[Robert Sesek, 2015/11/14 01:18:03]

I agree that it'd be good to centralize these. I added content_features to do so
(it doesn't seem like switches is the right place for these).

+#endif  // defined(OS_ANDROID)
+
 }  // namespace content
 
 #endif  // CONTENT_PUBLIC_COMMON_SANDBOX_INIT_H_