This (and the error text at line 68-69, "see build.sh") says build.sh does the --strip-debug, but build.sh doesn't strip anything. The strip comes from Gradle's NativeLinkTask.stripLibrary (strip --strip-debug on Linux, strip -S on macOS). The whole guard depends on .symtab surviving. So whoever later changes that task to --strip-all/--strip-unneeded needs to find this dependency, and this comment sends them to the wrong file. Could you point it at NativeLinkTask.kt instead? Ideally also add a back-reference comment next to stripLibrary saying this check relies on the symtab.

I doubt this marker ever fires on a real -O3 release build. SamplerPerfProbe is header-only, with an inline ctor/dtor, so I wouldn't expect any out-of-line _ZN16SamplerPerfProbe* symbol to be emitted. The test fixture's _ZN16SamplerPerfProbeD2Ev (t) models something a real build probably doesn't produce. In practice that leaves the sampler_ticks./sampler_count. strings as the only real detection for sampler-perf, while the tests suggest two independent layers. Could you check nm on an actual -PenableSamplerPerf release .so? If the symbol isn't there, either drop the marker or replace it with something that's guaranteed to survive.

This marker isn't tested on its own. The nm-faultinj fixture has crashNow and three _ZN8faultinj symbols, so deleting or mistyping this entry leaves the suite green. Yet it's exactly the marker that would catch a build where the faultinj:: helpers got inlined or gc-section'd away. Could you add a fixture with only _Z8crashNowv?

Sending nm's stderr to /dev/null drops the useful part when it fails, e.g. "file format not recognized" from a host-only nm on an aarch64 .so, or a truncated file. CI would then show just "nm failed on …". I'd let stderr through, or capture it and include it in the die message.

This path isn't tested. The stub defines FAKE_STRINGS_FAIL (test line 33), but no test case sets it. The command -v "tool not found" guards (lines 48-49) aren't covered either. Since the string markers are effectively the only reliable sampler-perf detection (see my comment on line 56), a regression that turned a strings failure into an empty STRTAB would silently disable them. Worth adding a test case for both.

Nit: this loop is a copy of the one above. The parsing, grep and FAIL message are the same; only the array and the text searched differ. A small check_markers "$haystack" "${ARR[@]}" helper would keep the two from drifting apart, e.g. if one ever loses the SIGPIPE-safe here-string. Minor, too: each here-string re-copies the multi-MB nm/strings output, six times in total. Writing each output to a file once and running a single grep -F -f would avoid that. Not a big deal at CI scale.

Related to @rkennke's check of the markers against the source: right now that check only happens by hand. Nothing keeps these arrays in sync with the code they detect, or with the list of flags:

• New flags aren't covered: if someone adds a 3rd hasProperty("enable…") next to ConfigurationPresets.kt:56, this script never checks for it, and a release build with that flag passes.
• Renames are unnoticed: the test fixtures (check_release_flags_test.sh:52-83) are copies of these markers; the suite never reads the source. Example: if "sampler_ticks.cpu" in counters.h is renamed, the suite stays green while sampler-perf detection falls back to the compiler-dependent SamplerPerfProbe symbol, or to nothing.