docs(android): a network filter replaces the built-in redaction; auto-init early window

[krassx]

Documents two by-design behaviours of the Android SDK's event filters. Every claim was checked against the SDK source on bugsee-android main; the SDK javadoc change is bugsee/bugsee-android#166.

F8: a network filter replaces the built-in redaction

• privacy/network.mdx: new section "A filter replaces the built-in redaction". It covers:
  • what the default sanitizer redacts (headers, sensitive query, JSON, form and key: value body keys, key-substring families, URL credentials, error messages; case-insensitive; %3Credacted%3E inside URLs);
  • a warning that installing a network filter, in code or in the manifest, turns the sanitizer off and makes the filter the only redaction;
  • Java and Kotlin examples that keep the built-in redaction by calling NetworkDataSanitizer.sanitize(event) inside the filter.
• network.mdx: one bullet pointing to that section.
• configuration/overview.mdx: the CaptureNetworkUseDefaultSanitizer row now says a manifest filter counts too.

F38: auto-init early window

The manifest sections of privacy/network.mdx, privacy/logs.mdx and privacy/breadcrumbs.mdx now say:

• with auto-initialization, capture can start before Application.onCreate(), and a filter set there in code misses what was captured before the call (for logs, that includes logcat lines read before then);
• the SDK installs a manifest filter itself as part of launch;
• use either a code filter or a manifest filter for a kind, not both.

Corrections to an earlier overclaim

All three manifest sections said the filter "is in force from the very first captured event, even under auto-initialization, before any of your own code runs". That is not true on current releases. The manifest filter is installed on a background thread after capture starts, so data from the first moments of launch can be recorded before it is in place. The sentence is replaced with what holds today.

Owner decisions

1. NetworkDataSanitizer becomes public API in practice. These docs point hosts at com.bugsee.library.shared.security.privacy.NetworkDataSanitizer, which sits outside com.bugsee.library.contracts.*. Options:
   • (a) accept it as it is;
   • (b) add a facade and point the docs there;
   • (c) revisit F8 and run the sanitizer after the host filter.
2. F41. A set*Filter(...) call (or a null clear) made while launch is installing a manifest filter can be overwritten by it, and the manifest filter then stays until the next set*Filter(...) call. This never results in unfiltered data. The "not both" advice covers it for now; the SDK fix is open.

Held back

This PR describes the released SDK. bugsee/bugsee-android#155 is now merged into bugsee-android main (ed665fce2), and a follow-up for the next SDK release is prepared, held locally on docs/android-filter-semantics-after-155. It changes two things:

• adds "declare the filter in the manifest to cover that window: Bugsee installs it before capture starts";
• replaces "use one or the other, not both" with the precedence after bugsee/bugsee-android#155: a code filter or null clear always wins, and using both is fine.

It will be published with the SDK release that contains bugsee/bugsee-android#155. The SDK-repo counterpart is bugsee/bugsee-android#166.

Validation

cspell (293 files, 0 issues; adds apikey and Credacted to the word list) and docusaurus build (no broken links or anchors).

🤖 Generated with Claude Code