Feature Request: Android Port

[Ermia01]

Problem

OmniGet currently only supports Windows, macOS, and Linux desktop platforms. Many users want to use OmniGet on Android phones to download courses and videos.

Proposed Solution

1. Android version — Port OmniGet to Android (can leverage the existing omniget-core Rust library + Android NDK)
2. Core feature reuse — omniget-core is already decoupled from Tauri, so download logic can be reused directly on Android
3. Material Design UI — Adapt to Android design guidelines for a native experience

Why

• Millions of users take online courses (Udemy, Hotmart, etc.) on their phones
• Android is the largest mobile platform with strong user demand
• omniget-core'''s architecture is already designed for cross-platform use

Environment

• Platform: Android 10+
• App: OmniGet

[tonhowtf]

Thanks for the thought-out proposal — and your read on omniget-core is right, which is exactly what makes the honest answer more awkward than a simple "no".

Where you're correct. omniget-core really is decoupled from Tauri, and the download engine really would port. Tauri 2 supports Android as a first-class target, so the shell isn't the blocker either.

Where the plan runs out. The download engine is a small share of what OmniGet actually is on the desktop, and almost everything else depends on things Android doesn't hand you:

• yt-dlp and FFmpeg. Both are external binaries the app downloads and executes. Android doesn't let an app execute arbitrary downloaded binaries from its data directory, and yt-dlp needs a Python runtime on top of that. Every Android yt-dlp app solves this by bundling a whole Python distribution (Termux-style or Chaquopy) — a large, ongoing maintenance burden, and it's the single biggest piece of work here, well ahead of the UI.
• The plugin system. Courses, Telegram, Convert and Study are native DLLs loaded at runtime and matched against the host's exact compiler fingerprint. Android's rules around loading native code from app data make the current design a non-starter, so the whole plugin architecture would need rethinking — and Courses is the reason most people mentioned in your "millions take online courses" line are here at all.
• Storage. Scoped storage means "pick a folder and write there" is a different model from the desktop's, so the entire output-path, rules-engine and library layer needs rework rather than reuse.

Add the reader, the player, the cookie manager and the browser-extension bridge, and "reuse the core" turns out to cover maybe a fifth of the app while the remaining four fifths need building against a platform with different rules.

Being straight about it: this is not something that gets picked up between bug fixes. It's a second product sharing a library, with its own release process and its own bug queue, and taking it on with the desktop app in its current state would mean both getting worse. So I'm not going to put it on the roadmap and let it sit there implying it's coming.

What I'd genuinely support is someone building it — omniget-core is open source and deliberately Tauri-free precisely so it can be reused. If you or anyone wants to start, say so here and I'll help with the core's API and keep it from drifting in ways that break you.

Leaving this open as the tracking issue for anyone who wants to pick it up, rather than closing it as unwanted — the request is legitimate, it just isn't something I can commit to.