Model installation fails after download reaches 100% (Microsoft Store certification)

[seydoudemon]

Description

My Flutter application uses flutter_gemma and was rejected by Microsoft Store certification because the model installation fails immediately after the model download reaches 100%.

Microsoft Store certification reported:

10.1.2.10 Functionality

Unusable Feature: The product displays an error message after the model download reaches 100%.
This was observed with an established internet connection.

Observed on:

• HP Spectre x360 2-in-1
• Windows OS build 22631.3296

The download itself appears to complete successfully, but flutter_gemma then reports an error during/after installation.

Environment

• OS: Windows 11
• Windows build: 22631.3296
• Device: HP Spectre x360 2-in-1
• Architecture: x64
• flutter_gemma: 1.6.3
• Model: Gemma 4 E2B
• Model format: .litertlm
• Distribution: Microsoft Store / MSIX

[DenisovAV]

Thanks for the detailed report. I dug into this on a packaged build; here is where it stands.

What I ruled out. My first theory was that MSIX file-system virtualization makes the write and the read-back diverge — flutter_gemma resolves its Windows storage dir from the raw %LOCALAPPDATA%, which is not container-aware. I built a minimal app, packaged it as a signed MSIX and ran it on Windows 11. MSIX does redirect those writes into the package container:

LOCALAPPDATA_env = C:\Users\<u>\AppData\Local
physically landed in
  C:\Users\<u>\AppData\Local\Packages\<PFN>\LocalCache\Local\flutter_gemma\...

But the redirection is symmetric — the same process reading back through the same path finds the file: exists = true, correct size. I then ran the real download inside the packaged app (same Task.split, same BaseDirectory.root handling flutter_gemma uses), including on a box where …\AppData\Local\flutter_gemma did not exist yet, which is a fresh install's state: TaskStatus.complete, file present, full size.

So the install path works under MSIX, and the theory is wrong. Whatever fails for you is something else.

Three things would narrow it down, the first most of all:

1. The exact error text your app shows. The report quotes the Microsoft reviewer's paraphrase ("displays an error message"). The real string says which stage failed — install verification, or the model load right after it.
2. Does it reproduce for you? Install your own MSIX on a clean Windows box and run the same flow. If it fails only on certification hardware, that points at the environment — free disk for a ~3 GB model, or network policy — rather than the code.
3. Your install call — the ModelSource, the fileType, and whether it fails at installModel(...) or at the first getActiveModel().

A debug or profile MSIX with console output would beat all three.

[seydoudemon]

Hello Sasha, really sorry for the late reply, I was busy with the Android app.

I performed a clean local MSIX test based on your path-mismatch hypothesis.

I removed the existing app and model data, built the application with:

dart run msix:create

and installed the resulting package:

build\windows\x64\runner\Release\omniask.msix

The MSIX application then downloaded the Gemma 4 model itself. It was not relying on a model previously downloaded by an unpackaged version of the app.

The model was stored at:

C:\Users\admin\AppData\Local\flutter_gemma\gemma-4-E2B-it.litertlm

The device-specific optimized cache was created successfully at:

C:\Users\admin\AppData\Roaming\com.demonventures\omniask\gemma-4-E2B-it.litertlm_1788275679_2588147712.xnnpack_cache

The model initialized successfully and I was able to use it for a chat. After restarting the MSIX application, it continued working normally.

The installed package was located under:

C:\Program Files\WindowsApps\OmniEcosystem.OmniAsk_1.0.0.0_x64__fxkeb4dgdm144

This indicates that the raw LOCALAPPDATA path is not universally incompatible with MSIX. However, the Microsoft Store reviewer still encountered the zero-byte installation failure, so the issue may depend on the Store installation environment or may be a timing/file-finalization race that did not occur during my local test.

I could not reproduce the failure locally, so I could not obtain the diagnostic file from a failing installation. For the next release candidate, I plan to expose the equivalent diagnostic information directly in the application when model installation fails. The UI will show or allow copying:

• the final download path;
• whether the file exists;
• the file size;
• LOCALAPPDATA;
• the application-support path;
• the application-cache path;
• the original installation error.

This should allow the Microsoft Store reviewer to provide the relevant runtime information through a screenshot or copied diagnostic text if the problem occurs again.

Please let me know whether you still need the LOCALAPPDATA, appSupport, and appCache values from the successful MSIX run.

[DenisovAV]

Thanks — and no apology needed. That is exactly the test I could not run, and it settles the path question from your side as well as mine: a packaged build downloading its own model, storing it at the raw LOCALAPPDATA path, writing the xnnpack cache under Roaming, initializing, and surviving a restart. Two independent measurements now say the raw path is fine under MSIX, so the theory is dead and we should stop spending time on it.

Direct answer to your question: no, I do not need the values from the successful run. The successful path is understood — what is missing is the state of a failing one, and that only exists on the reviewer's machine.

Your in-app diagnostic plan is the right move. Two refinements from what we know about the symptom.

The reviewer reported a zero-byte install. That shape matters: a download that fails normally throws, and the fields you listed would be captured on the error path — but a zero-byte file that the downloader considered successful never reaches that path. So capture the same block on the success path too, right after install() returns, and treat "file exists, size 0" (or size ≠ expected) as a failure your UI reports. Otherwise the one case you are chasing is the one case the diagnostics skip.

Worth adding to your list:

• The error's type, not just its message. DownloadError is a sealed class — UnauthorizedError, ForbiddenError, NotFoundError, RateLimitedError, ServerError, NetworkError, CanceledError, UnknownError. Printing error.runtimeType alongside toUserMessage() distinguishes a network stall from a 403 from a partial write without any guessing.
• Free disk space on the target volume. A model of this size on a fresh review VM is the classic way to get a truncated or zero-length file with no exception raised.
• Whether the file existed before the download started, and its size then — it separates "never written" from "written and truncated".

One thing about the reviewer's environment worth designing for: it is very likely a clean VM doing a first run — no cached model, a multi-GB download over whatever network policy the review lab has, and possibly a short time budget per app. If your diagnostics also show elapsed time and bytes received, a timeout or a policy-blocked transfer will be obvious at a glance rather than needing another round trip.

Leaving this open until your next release candidate goes through review. If it reproduces, the diagnostic text is exactly what I need; if it does not, we close it as an environment issue with the evidence recorded.

[omniseydou]

I got the above screenshot back from the Microsoft Store app reviewer(s). Let me know if this helps in any way