Lack of Built-in Audio Player in AnkiDroid Poses Long-Term Risk (Opus, Future Codecs)

AnkiDroid (Android) Suggestions
1

I would like to raise a concern about how audio is handled in AnkiDroid.

Currently, AnkiDroid relies entirely on the Android system to play audio files, instead of having its own built-in audio player. This creates a long-term risk for users who rely heavily on audio in their decks.

For example, I use the Opus format because it offers much better compression and quality compared to MP3, which helps me save a lot of storage space when dealing with thousands of audio files.

However, there are discussions about new audio formats like OAC (a potential successor to Opus). Even if this takes many years, it raises an important concern: what happens if Android eventually drops support for Opus?

If that happens, all AnkiDroid users who have large collections of Opus audio files may suddenly lose the ability to play their audio. Since AnkiDroid depends on the system player, there would be no fallback solution.

I understand that formats like MP3 have remained supported for decades, largely due to their universal adoption. Because of that, if MP3 support were ever at risk, it would likely receive much more attention and faster solutions.

Opus, on the other hand, is less widely used by the general public, especially within Anki decks. This could mean that potential compatibility issues might not receive the same level of urgency, leaving some users more vulnerable.

This becomes even more concerning when thinking about the future. What if someone wants to use, share, or even sell their decks 40–50 years from now? If the audio format is no longer supported by the system, those decks could become partially unusable.

Converting thousands of audio files later would also be extremely difficult and time-consuming.

Because of this, I would strongly suggest considering the implementation of an internal audio player in AnkiDroid, with built-in support for formats like Opus. This would ensure long-term compatibility and protect users’ data regardless of changes in Android.

Thank you.

2

Converting thousands of audio files later would also be extremely difficult and time-consuming.

It feels like the post is predicated on this line, and it’s not the case. Bulk media conversions are trivial.

This isn’t going to be on the roadmap. We’re time/effort constrained, and I’d rather focus on user-facing improvements, rather than spend significant dev effort protecting against the chance that a bad decision is made 20 years from now.

When it’s likely to be an issue, please re-post. I can’t see this being close to relevant for at least a decade, but time will tell.

3

I understand your point, but I think the situation is more complicated in practice.

Converting thousands of audio files is not as easy as it sounds. On mobile, it is often only possible to convert small batches (for example, around 20–30 files at a time). When you have thousands of files — and the number keeps growing every day — this becomes a very slow and repetitive process.

There is also another major issue: newer versions of Android restrict access to the Android/data folder, and AnkiDroid stores its media files there. This means users cannot easily access or modify their audio files directly on their phones.

In addition to that, the file names must match exactly the names referenced inside the Anki notes. This creates a second layer of work: not only do you need to convert the audio files, but you also need to rename them and update the references inside Anki.

There is a “Find and Replace” feature, but it is only available on desktop. On mobile, even if such a feature were added in the future, it would likely be very limited — similar to batch conversion — where you can only process small amounts at a time. Otherwise, the device may lag or even freeze.

Yes, there are some workarounds, but they usually require a computer. The problem is that many people today do not have access to a computer, and internet cafés are no longer common. Even worse, these workarounds may stop working in the future due to further Android restrictions.

I understand that this might seem like an exaggerated concern, but I believe it is a real and practical issue, especially for users who rely heavily on audio.

I also feel that if this were about MP3, there would be more urgency, because it is widely used. But since this involves Opus — which many users are not familiar with — it may not receive the same level of attention, even though it offers better quality and smaller file sizes.

Because of all this, I still think it would be valuable to consider a more robust long-term solution, even if it is not a priority right now.

4

Working on this would be diverting work away from efforts such as this, and for no user-perceptible benefit:

5

Thank you for your response.

I understand that this may not seem like a priority right now, but I would like to clarify that this concern is not purely theoretical — especially for Android users.

On modern Android versions, access to the /Android/data folder is heavily restricted. In practice, many users cannot directly access, batch-process, or modify their own media files stored by apps like AnkiDroid. This is not just an inconvenience — it is a system-level limitation.

Because of this, if Android ever drops support for a format like Opus, users with large collections may not only face difficulty, but may be effectively unable to convert their files at all. The common suggestion to “just convert them” assumes file access that many users simply do not have.

In real-world scenarios, this goes beyond being time-consuming — it can become practically impossible for non-technical users.

Additionally, AnkiDroid relies entirely on the system for audio playback and does not provide an internal fallback player or bulk media management tools. This means users are fully exposed to any future codec changes at the OS level.

So this is not about optimization or convenience — it is about long-term accessibility and durability of user data.

I understand that this is not an immediate issue, but it is the kind of problem that only becomes critical when it is too late to address easily.

For that reason, I believe it is worth considering at an architectural level, even if it is not prioritized right now.

Thank you for your time.