Network Audit for Third-Party SDKs in Local AI

Direct answer

A third-party SDK network audit asks what requests occur when a specific app action runs, not merely which SDKs are listed in a package. The test must record a build, device, connectivity state, action, request timing, host, method, payload class, and observed response. PRIVACY-01 and PRIVACY-02 support keeping user data boundaries explicit. Android Studio Network Inspector can display supported HttpsURLConnection and OkHttp traffic, but a missing event is not proof of no networking: other libraries, native sockets, or process boundaries may not appear in the view. Start from a static inventory and create a trigger matrix. Include cold launch, model setup, opening a screen, a local inference task, cancellation, crash or error handling, feedback, export, and settings changes as separate actions. Run a baseline before each trigger, then capture only one action at a time with synthetic inputs. Distinguish traffic caused by app code, SDK initialization, operating-system services, and the document or media provider. If attribution is uncertain, mark it unknown instead of assigning a hostname to an SDK by guess. Use a controlled test environment with an inspectable build and a network capture method appropriate to the protocol. Record the limitations of TLS interception, certificate pinning, unsupported libraries, background workers, and DNS or connection setup. Do not disable certificate validation in the app to force capture. If a request cannot be inspected, preserve the endpoint, timing, byte counts if observable, trigger, and reason the payload is unavailable, then use source and SDK documentation as secondary evidence. This is a bounded audit, not a proof that every channel was seen. Prepare canary strings for prompts, transcript snippets, image labels, account identifiers, and local file names. Use only synthetic content. Check whether exact values or transformed derivatives appear in request bodies, headers, query parameters, logs, analytics, or crash records. Compare the same action in a feature-disabled build or with the SDK’s documented opt-out applied. A control comparison can reveal a path, but a quiet run does not establish that no other feature or code path can send data. For every observed destination, record who operates the domain if verified, the SDK or feature path that initiated it, whether it was necessary for the requested action, which data classes were present, and whether the user could prevent it. Do not infer the recipient from the domain name alone. A CDN, metrics endpoint, identity service, or support API may belong to different organizations. Keep a verified operator source link and separate it from unverified attribution. Repeat after changing one variable: cold versus warm launch, logged-in versus anonymous state if the app supports both, connected versus blocked network, model asset present versus missing, and release versus debug build. Do not vary several flags simultaneously. Verify cancellation stops or labels continuing work; queued background requests may outlive the screen. The report should include requests after reconnect as well as during a disconnected attempt. The final result describes observed traffic for named actions and a named build. It cannot promise no data leaves the device based on one airplane-mode test, one proxy capture, or an empty inspector panel. Document coverage and blind spots, then link findings to the static SDK inventory and user-facing data disclosures. Re-run after dependency changes, new telemetry events, or new fallback routes. This method helps expose data paths while avoiding an unsupported zero-network guarantee.

A tester checks whether a local inference action starts a third-party request

A QA reviewer has a release candidate with several libraries and wants to verify whether tapping a local text-assistance action triggers a request. A cached screen and a single Network Inspector capture are not enough to establish behavior, so the reviewer needs controlled triggers and a clear account of capture limits.

Decision

Compare a no-action baseline with one synthetic task at a time, attribute only verified requests, and explicitly record traffic that available tooling cannot inspect.

Expected outcome

The report names observed destinations and payload classes for this build without claiming all network activity was visible.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• SDK inventory
• Traffic and payload capture
• Feature-off result

A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.

Implementation workflow

1. Pin the build and static SDK list. Record app artifact, build variant, dependency versions, network libraries, SDK inventory, device, OS, and test account state before capture for reproducibility.
2. Define one-action trigger cases. Test cold start, model setup, one inference, cancellation, feedback, export, and error states separately with synthetic canary values per app action.
3. Capture and label network observations. For each request record time, host, method, trigger, payload class, response, and whether attribution is verified or still unknown after source review.
4. Compare feature-disabled and blocked-network runs. Change one variable per run, inspect background work and reconnect queues, and preserve known blind spots such as uninspectable native traffic.
5. Map findings to controls and disclosure. Identify verified operators and user controls, then compare observed paths with documented feature purpose and privacy statement for this build.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• Each observation is tied to a specific build and action with capture limitations explicitly recorded.
• Synthetic canaries are not present in observed payloads unless the test documents the exact purpose and approved path.
• The report distinguishes observed requests from unknown or unobservable traffic and makes no zero-network guarantee.

Decision table

Failure patterns to prevent

• Assuming an SDK is dormant
• Ignoring initialization requests

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Cove network audit
• Android Studio Network Inspector
• Android network state and validated connectivity
• Google Play SDK requirements

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions