Direct answer
Treat personal and managed work profiles as separate app-data owners. Android isolates their storage, and the work profile is subject to IT policy. A model choice, file, worker record, or ready flag in one profile does not prove the other has that artifact. Decide whether each needs an independent copy or the user explicitly needs a transfer. Inventory the current user/profile, artifact revision, local and temporary paths, worker attempt, and ready state separately. Resolve paths through that profile's context; do not infer from another profile's state. Cove's downloader fact covers one configured temporary directory, not two-profile behavior or enterprise support. Use WorkManager for work intended to persist across app exits or reboots; it is not a cross-profile service. Bind each operation to its owner profile, artifact revision, attempt, and path. Unique-work names coordinate within an app instance, not across profiles. Test retry, cancel, and restart separately in each instance. Sharing is an explicit handoff, not a shared-path lookup. A file:// URI is not valid in the other profile. A content:// URI from a scoped FileProvider can work only if the provider exposes the file, the Intent grants temporary access, and policy allows crossing. Default to read-only; grant write only for an explicit editing feature when the user and policy permit it. The receiver opens the URI through its content resolver and copies to a profile-local candidate if it needs a durable model. Context.grantUriPermission() alone grants only within one profile. A content URI is not universal access, nor does this guide prohibit authorized model edits. Most intents are blocked across profiles unless policy allows them. Intent.resolveActivity() is a preflight, not a lasting guarantee: policy, profile availability, handler state, or package visibility can change. On Android 11+, declare only necessary <queries> visibility. Attempt launch and handle ActivityNotFoundException, SecurityException, provider errors, or revoked grants without deleting the source or reporting a successful import. Test pause, resume, and removal only on a disposable managed-profile setup, never a user's actual profiles. Do not infer that pause finishes a transfer or that removal shares or deletes files in the other profile. Inspect each test instance's worker and file state. Record profile, artifact, owner, URI grant, policy, and outcome without logging prompts or model input. This method does not establish Cove enterprise support or universal sharing behavior.
A user wants the same offline model in personal and work apps
The same local-AI package is installed in personal and managed work profiles. A model downloaded in personal is expected to appear ready at work, but policy may block sharing and the instances are untested together.
Decision
Keep model state profile-owned. Transfer only after user intent and admin policy allow it; validate a destination copy inside the receiving profile before marking that instance ready.
Expected outcome
Each profile reports its own asset and worker state. A blocked or revoked handoff keeps the source intact and the receiver not-ready with a recovery action.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Per-profile artifact and worker records
- Allowed Intent and temporary read-grant tests
- Disposable profile lifecycle fixtures
A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.
Implementation workflow
- Identify both profile contexts. Use a disposable managed-profile test setup and record Android user/profile, package/build, work-profile policy, and which app instance initiates each operation. Do not infer context from a badge or application ID alone or operate on a user’s actual profile.
- Inventory asset state separately per profile. Record model revision, local path, temporary candidate, active pointer, worker attempt, and readiness in each profile. Inspect bytes through that profile context; one profile’s downloaded flag or path does not cover the other.
- Bind each background transfer to its owner. Key work by executing profile context, artifact revision, and attempt. Exercise enqueue, retry, cancellation, and process restart in one profile while verifying the other does not claim that worker or file.
- Choose a least-privilege handoff only after approval. If transfer is necessary, test a content:// URI from a permitted provider and grant temporary read access in the Intent by default. Add write access only for an explicit editing feature when the user and admin policy permit it. Avoid file:// paths and broad storage access; an admin may block the Intent.
- Handle intent and URI failure at launch. Use resolveActivity() as a preflight and declare narrow package visibility if needed. Still launch and catch ActivityNotFoundException, SecurityException, and provider failures; preserve source bytes and offer retry, separate download, or cancel.
- Test profile pause, resume, and removal. Use a disposable managed-profile test setup, not a user’s personal or work profile. Pause and resume it during a test transfer, then test removal only if in scope. Inspect worker state and files in each surviving profile; do not infer automatic sharing or deletion from profile lifecycle events.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- The artifact, temporary path, worker attempt, and ready state are recorded separately for the personal and work profile contexts; neither profile inherits the other’s ready flag.
- File URIs are not used across profiles; a content-URI handoff has an authorized provider, least-privilege temporary read grant by default, a receiving-profile read test, and allowed cross-profile policy. Write access is added only for an explicit authorized editing feature.
- Intent preflight is followed by actual launch and error handling, including policy or package-visibility failures, without deleting source data or reporting a failed import as ready.
- Pause, resume, and any tested profile removal use a disposable managed-profile test setup and have observed outcomes; no behavior is inferred as Cove support or a universal enterprise guarantee.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Personal and work profile copies | Independent profile-local assets and workers | Safest default ownership model; each profile verifies and maintains its own model readiness. |
| file:// path in a cross-profile Intent | Do not use as a handoff | The path belongs to the sender profile’s storage and is not a valid access route in the other profile. |
| Authorized content:// handoff | Grant narrow temporary access in an allowed Intent | Can expose a selected file if provider, URI grant, receiving context, and profile policy all permit it; it is not automatic shared storage. |
| One unique-work name in both profiles | Treat each profile context as a distinct owner | A per-instance scheduler record is not proof of a global lock or shared transfer across profiles. |
Failure patterns to prevent
- Treating one profile path as globally shared
- Granting write access for read-only model import
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
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
- Android privacy and security
- Android persistent background work
- Android Developers — Work profiles
- Android Developers — Android Enterprise developer guide
- Android Developers — Share files securely with content URIs
- Android Developers — Package visibility
- Android Developers — Persistent background work
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
If the same APK is installed in both profiles, do they share the downloaded model?
Do not assume so. Android separates app data by profile. Check the artifact and ready state in each context; a personal download does not prove the work instance can read it.
Can I send the model path to the work profile with a file URI?
No. A file URI is a path in the sender profile, so the other profile cannot use it. Use a content URI only when the provider, Intent grant, and admin policy allow access.
Will a content URI always work across the profile boundary?
No. The provider must expose the file, the Intent must grant temporary read access, and policy must allow crossing. Add write access only for an explicit authorized editing feature. Test the receiving profile and handle denied or revoked access.
Does resolveActivity() guarantee the handoff will still launch?
No. It is a snapshot; policy, package visibility, or profile state can change before launch. Declare needed queries, attempt the Intent, and handle ActivityNotFoundException and SecurityException.