Direct answer
A release notice review starts with the contents users actually receive, not only the direct dependency file or the model card. An Android local AI feature can combine application code, transitive libraries, native runtime components, tokenizer or image processors, conversion tools, bundled assets, and files downloaded after install. These items can have different publishers and licenses. Create one inventory per release variant and keep each component tied to its exact version, source, and delivery path. A source archive, an APK, an app bundle split, and a separately downloaded model package may not contain the same components. For every item, preserve the upstream license text or authoritative terms URL, the version or revision to which it applies, a machine-readable identifier when one accurately matches, and any stated notice, attribution, source-offer, modification-marking, or redistribution condition. SPDX identifiers help identify common license texts consistently; they do not interpret a custom model agreement or prove that the identifier is correct. If the exact artifact license is ambiguous, record the ambiguity and stop short of publishing a clearance conclusion. Model-family names can span base, instruct, quantized, or converted files with different provenance and terms. Separate code dependencies from model artifacts and from tools used to produce them. A build-time converter may not ship in the application, but its output still needs provenance and a license review. A model downloaded on demand is still part of the product delivery experience even if its bytes are absent from the APK. Likewise, an OSS notice generated from Gradle dependencies will not necessarily discover model files fetched by a repository, a server, or a first-run download. Reconcile the dependency graph with the actual packaged files and documented model source. Do not infer obligations from labels such as “open,” “community,” or “commercial use allowed.” Read the exact license and version. Apache License 2.0, for example, includes conditions involving preservation of notices and a copy of the license; that example does not establish terms for another library or any model. SPDX is a catalog and expression vocabulary, not a legal decision engine. The record should identify which source was reviewed and by whom, and point unresolved questions to a qualified reviewer rather than converting them into a blanket approval. A useful release check has two directions. First, every delivered component should map back to an authoritative license source and a release artifact. Second, every applicable notice or attribution should appear where the product actually distributes or exposes it, such as an in-app notices screen or an accompanying file when that is the chosen channel. Check language, offline availability, and whether a notice remains accessible after installation. Do not assume a web page or repository file travels with a downloaded model. Finally, preserve change history. A dependency upgrade, new quantization, repackaged tokenizer, changed model source, or switch from bundled to downloaded delivery can alter the inventory. Compare revisions, regenerate the component list, and review changed license texts rather than copying last release approval forward. This checklist produces traceable evidence for a release review; it does not guarantee legal compliance, provide legal advice, or certify that a model may be redistributed.
A new model conversion joins an existing Android release
A team already publishes an app with a permissively licensed native runtime. It now converts a separately sourced model and plans to offer the files from its own download endpoint. The existing software notice file lists Gradle dependencies but does not mention the downloaded model, tokenizer, or conversion tooling.
Decision
Create a release-specific component inventory across app code, native libraries, tooling, and downloaded artifacts; attach exact license sources and review notice placement before describing redistribution status.
Expected outcome
The release record shows what was reviewed and what remains unresolved. It does not infer that the model shares the runtime license or announce a legal conclusion.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Dependency and artifact inventory
- License source records
- Release notice verification
A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.
Implementation workflow
- Freeze the release and delivery variants. Record application version, build variant, package or bundle outputs, dynamic features, model delivery channel, and the exact release candidate. Analyze the package and separately downloaded files as distinct delivery artifacts.
- Build a component inventory from multiple sources. Combine resolved direct and transitive dependencies, packaged native libraries, bundled assets, model and tokenizer manifests, conversion tools, and any server-side files delivered to users. Record source, version, owner, and whether the component is shipped or only used during build.
- Attach the authoritative terms to the exact revision. Link the upstream license text or terms page and note the exact artifact revision. Use an SPDX identifier only where the license text matches; record custom or unclear terms verbatim by URL and route them for review.
- Map conditions to a notice location. For each reviewed license, extract the actual notice or attribution requirement into a tracked action. Confirm that the selected in-app or accompanying notice is included in the release channel and remains available offline if the product relies on local assets.
- Review changes and unresolved decisions. Compare this inventory with the previous release, flag new files, changed terms, missing license texts, and artifacts whose upstream source cannot be pinned. Keep unresolved items open and obtain review before making a redistribution statement.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Every delivered model, runtime, native library, tokenizer, and bundled tool is listed with exact version or revision, source, delivery path, and license evidence.
- SPDX identifiers are used only when they match the reviewed text; custom or uncertain terms remain visibly unresolved.
- Required notices are mapped to an actual release location and checked against the same artifact set that users receive.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Dependency-only notice scan | Generate notices from the build dependency graph | Useful for declared code dependencies, but may miss model assets, external downloads, converters, or packaged components outside that graph. |
| Release component inventory | Reconcile dependency, package, asset, tool, and delivery evidence | Provides a reviewable map of shipped inputs but still depends on accurate sources and human interpretation. |
| Legal clearance | Qualified review of exact terms and intended distribution | Addresses legal interpretation for the actual release; a generated notice report alone does not provide this conclusion. |
Failure patterns to prevent
- Assuming one family license
- Dropping notices after conversion
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
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Does an SPDX identifier prove that a model is approved for redistribution?
No. It is a standardized identifier for a license expression when the source is correct. The exact artifact terms and intended distribution still need review, especially for custom model agreements or converted files.
If a model is downloaded after installation, can it be omitted from notices?
Do not assume that. It is part of the product delivery path even if it is not inside the APK. Record the source, revision, license, download host, and how any required notices reach the recipient.
Can last release approval be reused after updating a tokenizer?
Not without checking the changed artifact. A tokenizer or processor can have a separate source and license, and a new revision changes the component inventory. Review the exact new file and terms.