Split out of #546 so the question survives PR #735 merging — right now it exists only in that
PR's second comment, which stops being findable once the PR closes.
The state #735 leaves behind
#546 made crash reporting opt-in, and only ever opt-in, for the FOSS distribution: a first-run
sheet shown once, a Settings › Support switch, and collection defaulting off. The Google/Play
distribution is deliberately unchanged and still collects by default via Crashlytics (#233).
Worth being precise about what that means, because it is easy to read as an oversight: before
#735, both distributions were on-by-default from the same shared line. #735 did not introduce the
asymmetry — it fixed one half and left the other exactly as it was, under a
crashReportingRequiresOptIn flag (true foss / false google) with both values pinned by tests
in their own source sets.
Why it was left, and why that argument is not obviously wrong
Distribution here is a build flag, not a flavor (#467). The Google build binds
FirebaseCrashReporter and its CrashReporterInitializer is a no-op, since Crashlytics
self-initializes.
The Google build ships no consent surfaces at all. So flipping the flag there today would
disable Crashlytics with no way for a user to turn it back on — strictly worse than either
coherent end state. Fixing it properly means shipping the sheet and the Settings row on that
distribution too, not flipping a boolean.
The actual question for @Monkopedia
Should the Google/Play distribution also become opt-in?
Three coherent answers, and the right one depends on facts outside the code:
- Yes — port the consent surfaces. The sheet and Settings row already exist and are
distribution-agnostic; the work is wiring, not design. Consistent story, one privacy posture,
and the honest reading of "only ever opt-in" as a principle rather than an F-Droid concession.
- No — Play is a different bargain. Play listings disclose crash collection through the Data
safety form, users are not selecting the build for the property F-Droid users are, and
Crashlytics is how the app is actually debugged in the wild. Then the FOSS/Play split is a
deliberate product position — worth writing down somewhere durable rather than living in a flag.
- Yes, but later — after the F-Droid MR (
fdroiddata!42096) lands, so the time-sensitive half
is not held up by the half nobody is asking about.
This is not urgent and nothing is blocked on it. The F-Droid problem is solved by #735; the
listing claims become true for the build that makes them.
One thing to check whichever way it goes
The Play listing's Data safety declaration should match reality either way. If the answer is (1),
that declaration changes too.
Related: #546 (the FOSS fix), #233 (wired Crashlytics originally), #467 (distribution as
a flag), #516 (ANR reporting — needs-decision, must inherit whatever gate applies).
Split out of #546 so the question survives PR #735 merging — right now it exists only in that
PR's second comment, which stops being findable once the PR closes.
The state #735 leaves behind
#546 made crash reporting opt-in, and only ever opt-in, for the FOSS distribution: a first-run
sheet shown once, a Settings › Support switch, and collection defaulting off. The Google/Play
distribution is deliberately unchanged and still collects by default via Crashlytics (#233).
Worth being precise about what that means, because it is easy to read as an oversight: before
#735, both distributions were on-by-default from the same shared line. #735 did not introduce the
asymmetry — it fixed one half and left the other exactly as it was, under a
crashReportingRequiresOptInflag (truefoss /falsegoogle) with both values pinned by testsin their own source sets.
Why it was left, and why that argument is not obviously wrong
Distribution here is a build flag, not a flavor (#467). The Google build binds
FirebaseCrashReporterand itsCrashReporterInitializeris a no-op, since Crashlyticsself-initializes.
The Google build ships no consent surfaces at all. So flipping the flag there today would
disable Crashlytics with no way for a user to turn it back on — strictly worse than either
coherent end state. Fixing it properly means shipping the sheet and the Settings row on that
distribution too, not flipping a boolean.
The actual question for @Monkopedia
Should the Google/Play distribution also become opt-in?
Three coherent answers, and the right one depends on facts outside the code:
distribution-agnostic; the work is wiring, not design. Consistent story, one privacy posture,
and the honest reading of "only ever opt-in" as a principle rather than an F-Droid concession.
safety form, users are not selecting the build for the property F-Droid users are, and
Crashlytics is how the app is actually debugged in the wild. Then the FOSS/Play split is a
deliberate product position — worth writing down somewhere durable rather than living in a flag.
fdroiddata!42096) lands, so the time-sensitive halfis not held up by the half nobody is asking about.
This is not urgent and nothing is blocked on it. The F-Droid problem is solved by #735; the
listing claims become true for the build that makes them.
One thing to check whichever way it goes
The Play listing's Data safety declaration should match reality either way. If the answer is (1),
that declaration changes too.
Related: #546 (the FOSS fix), #233 (wired Crashlytics originally), #467 (distribution as
a flag), #516 (ANR reporting —
needs-decision, must inherit whatever gate applies).