"No key, no SDK" is not a guarantee on Android: the manifest merger gets there first

Two configuration channels were open in this project, and only one of them was ever read. The DSN lived in a gitignored `local.properties` and reached Kotlin through `BuildConfig.SENTRY_DSN` ^[2]. The self-initialising path reads a DSN from `io.sentry.dsn` manifest meta-data, which this project deliberately never sets ^[9][10]. The two channels do not meet, so the decision that kept the key out of version control is the same decision that guaranteed the provider would find nothing and throw during process startup ^[1].

That also means the green build-with-a-DSN was not a second data point. `SentryInitProvider.onCreate` calls `SentryAndroid.init` with no options lambda ^[9], so it never consults `BuildConfig`, and the variant compiled with a real DSN would have died in the same place ^[2]. Both variants were checked by compiling them, and compiling is not the phase where this breaks.

The ordering is the whole mechanism. A ContentProvider is installed before `Application.onCreate()` runs ^[8], which puts every gate an operator normally writes there downstream of every provider a dependency contributed to the merged manifest ^[3]. A consent check or a branch on a build flag is code that gets its turn after the SDK has already had one. The only condition actually guarding this provider is `ManifestMetadataReader.isAutoInit`, read from manifest meta-data and defaulting to true when the meta-data is absent ^[9]. The enforceable switch therefore sits in the manifest, alongside the provider declaration, not in application code ^[4]. A gate in your `Application` class and a gate in the merged manifest are not two ways of expressing one policy; only one of them is in the process early enough to matter.

The verification gap follows from the same ordering. The four checks that passed were a build with the DSN, a build with a blank DSN, `./gradlew test`, and an iOS cross-compile ^[4]. None of them installs an APK, starts a process, or instantiates a ContentProvider ^[11], and the fault lives after compilation and before the author's first line ^[12]. The guard was real, commented, and never once in force ^[14]. What did find it was reading `app/build/intermediates/merged_manifest/release/AndroidManifest.xml` and seeing a provider nobody wrote ^[7], plus a phone.

Note who filed the report. Not the crash reporter, which cannot report its own startup failure ^[6]; logcat did, on a device, at 100 percent of launches ^[5]. That is consistent with the other finding in the same integration a few hours earlier, when two privacy leaks became visible only by intercepting the actual outbound bytes, one of them carrying a lifter's shoulder injury note in a request payload ^[13]. Both bugs were invisible to source review and visible to observation of a running process.

For anyone shipping an SDK behind a flag on Android, the useful question is not whether the flag is correct. It is which layer the vendor chose to start itself in, and whether your off switch lives in that layer too.