Discuss extending `addMediaFile` to accept a file path

[david-allison]

The backend AddMediaFile only accepts a byte array, not a file reference

message AddMediaFileRequest {
  string desired_name = 1;
  bytes data = 2;
}

This increases memory pressure on AnkiDroid for large files, as it does not support streaming , leading to OurOfMemoryError.

We may wish to implement this upstream, or as an AnkiDroid-only extension to the backend

[shivraj1182]

@david-allison, Hi, Again! As I can see, the parent issue is partially resolved (error handling part is done) but the architectural fix and the user warning system is still needed. I'd like to work on issue #608 if nobody else is working with it.

[shivraj1182]

@david-allison, Hi, Again! As I can see, the parent issue is partially resolved (error handling part is done) but the architectural fix and the user warning system is still needed. I'd like to work on issue #608 if nobody else is working with it.

I propose the protocol buffer file that defines the AddMediaFileRequest message and the MediaService RPC to be edited to modify the AddMediaFileRequest message to optionally accept a file_path field in addition to (or instead of) the data field. And I've created a PR for the same. Please review it. Thanks.

[david-allison]

This issue exists as a discussion point. There's a few strategies we can take regarding implementation. You've ignored this and skipped to a broken implementation, please don't do this.

Firstly, please link PRs:

• feat(proto): extend AddMediaFile to accept file paths for streaming s… ankitects/anki#4455

Secondly, your PR is adding negative value. Please close it.

1. If we are sending a PR upstream, we want to be sure it's high quality and not wasting time, and want to be sure we're roughly on the same page and have discussed upsides and downsides. None of this has occurred
2. It doesn't compile; all you've done is deleted code

[shivraj1182]

Hey! @david-allison I apologize for jumping ahead without any proper discussion. I'm new to Open-Source, I might do mistakes very often.
For this issue (#608):
I'm closing/withdrawing my PR on this one. Let me re-approach it properly:
According to my understanding, the parent issue #19578 is about handling OutOfMemoryError in addMediaFile and this issue (#608) is discussing how to extend addMediaFile to accept file_path, we need to modify the AddMediaFileRequest message to include optional file_path field and need discussion on implementation strategy before coding. Please point if I am wrong...

I'll wait for feedback before writing any code. Thanks for the guidance.

[BhumikaTechHub]

Since addMediaFile currently requires the full payload as a bytes field, AnkiDroid has to read the entire media file into memory before passing it to the backend. On Android, this is risky for larger audio/video files and aligns with the reported OutOfMemoryError , particularly given tighter heap limits compared to desktop.

It seems there are two possible directions to address this:

**An upstream change to the backend API (e.g. allowing file-based or streaming input), which would be the cleanest long-term solution but would require coordination across platforms and a careful migration path.

An AnkiDroid-specific extension or workaround, which could reduce crashes sooner but would introduce some platform-specific handling and potential technical debt.**

At this stage, it feels most valuable to first align on the preferred direction and constraints before getting into concrete API or implementation details. I’d be happy to help by documenting the Android memory implications more clearly, testing proposed approaches on-device, or validating behavior once a direction is chosen.

[david-allison]

At this stage, it feels most valuable to first align on the preferred direction and constraints before getting into concrete API or implementation details. I’d be happy to help by documenting the Android memory implications more clearly, testing proposed approaches on-device, or validating behavior once a direction is chosen.

The memory case doesn't seem relevant (obvious).

Digging into using a file descriptor seems useful, intuitively this seems like the best approach

The main questions (off the top of my head) are the architectural implications:

• should we use a path or a file descriptor?
• is a protobuf string suitable for paths
  • Anki uses it, but it doesn't support UTF-8 + unpaired surrogates (WTF-8 encoding)
• Is it safe to expose 'filesystem access' via the backend, rather than having methods act within the collection
  • Is there any precedent? This is especially important from a security perspective if AnkiDroid has MANAGE_EXTERNAL_STORAGE permissions on non-Google Play Builds

[dae]

Security definitely needs to be considered. Anki has another method that accepts arbitrary file locations for image occlusion, and this was used in a proof of concept exploit to read+exfiltrate arbitrary files from the reviewer in the past. If similar methods are introduced in the future, it's imperative they're not accessible by any webview that may be include third-party code.