Test Login Dependencies in an Offline Translator

Direct answer

A login-dependency test asks which user tasks actually require an account and which continue with local state; it should not assume either “login is always required” or “offline means account-free.” `PRIVACY-01` defines the limited claim that local inference removes the need to send content to a remote inference server, but it does not prove that other requests are absent. `ARCH-02` allows a hybrid architecture where some tasks stay local and others use a remote service; routing and transmitted data must be explicit. These facts make account status, network state, and inference route separate test variables. Map each screen and action: fresh install, first launch, language asset setup, account creation, sign-in, entitlement check, new translation, history read/write, export, restore, and sign-out. For each, record whether the app permits a signed-out path, what data is local, and which endpoint or platform dependency appears. A cached session is not proof that login is unnecessary; repeat the test after clearing app data or revoking a token only in a controlled test account. Do not use a real account's private messages as fixtures. Test account state independently from connectivity. Use a test identity with no sensitive data, and test signed out, valid session, expired session, explicit sign-out, and account service unavailable. Then test connected and network-blocked conditions for each state. Observe whether translation uses an already installed artifact, whether a remote request is attempted, whether an entitlement gate affects only a paid feature, and whether local history remains readable. Do not infer product policy from a sign-in screen or terms page alone. Inspect both code and traffic. Android Network Inspector can show supported OkHttp and HttpsURLConnection flows, but not every possible client; include dependency and call-site review. Record request destination and payload category without capturing real user content. If a remote route is optional, check that declining it leaves the local task available where the product promises that behavior. If an account is required for setup or another feature, state that exact boundary. Do not call an app “no-login” when only an existing token was reused or an account check was served from cache. Recovery cases matter. Simulate session expiry during asset setup, after translation, and before export. Verify the app does not discard user-created history or transmit content as a silent fallback. Make sign-out behavior explicit: does it clear credentials only, remove cloud-linked data, or leave local data? Verify the actual implementation and explain each result. If local content remains after sign-out, do not state that it was deleted. If access to a paid entitlement requires a network check, distinguish that from the model's execution location and disclose the limitation. The final record includes app build, account-state fixture, network controls, installed asset state, action sequence, observed requests, local output, and failure path. Report only what the test can support—for example, “this local text task completed while signed out after the asset was installed in the tested build.” Do not expand that to every mode, language, first-run condition, or phone. This method reveals hidden sign-in dependencies without inventing app policy and separates local inference from account, billing, downloads, analytics, and support requests.

A traveler signs out before testing an installed translation asset

The user wants to know whether an already-installed text workflow still works when the account service cannot be reached. The app may also expose history and a paid feature with separate checks.

Decision

Test sign-in state and network state as separate dimensions, keep fixtures synthetic, and trace local task, entitlement, history, and export independently.

Expected outcome

The report identifies the exact task and setup state that worked or failed without calling the whole application account-free.

Evidence to collect

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

• Anonymous and signed-in state map
• Blocked-network task fixtures
• Entitlement, translation, and recovery results

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

Implementation workflow

1. Draw an action-to-account map. List install, first launch, asset setup, sign-in, entitlement, translation, history, export, restore, and sign-out. Mark expected account and network dependencies as hypotheses to verify.
2. Create controlled account states. Use a dedicated test identity with synthetic content. Exercise signed-out, valid, expired, explicit sign-out, and service-unavailable states without reusing private user data.
3. Cross account state with connectivity. Repeat each task online and with network blocked. Record whether assets are preinstalled, a request is attempted, a gate appears, and local records remain available.
4. Inspect code, requests, and payload boundaries. Use supported traffic inspection plus dependency and call-site review. Note tool blind spots and record destinations/categories without capturing private prompts or account content.
5. Exercise expiry and recovery. Expire a session during setup and before export; verify user history is not lost and no silent remote fallback occurs. Confirm sign-out behavior against code.

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

Acceptance criteria

• Account state, network state, installed asset state, and task type are recorded separately for every run.
• The report identifies any sign-in or entitlement gate and confirms whether local history/export behavior matches the observed implementation.
• Traffic inspection scope and blind spots are documented; no broad “no-login” or zero-network claim is inferred from a cached session.

Decision table

Failure patterns to prevent

• Calling cached sessions account-free
• Blocking local data export behind login

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

• On-device and hybrid routing boundary
• Android Credential Manager overview
• Android Studio Network Inspector
• Android security and privacy overview

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

Frequently asked questions