FooIbar/EhViewer: A Material Design 3 Fork of the E-Hentai Android Client

What FooIbar/EhViewer actually is, and who it is for

This is an Android application written in Kotlin, not a service and not a web front end. The README describes it as "a modern EhViewer fork dedicated to high-performance" with Material Design 3 and Dynamic Color support. It is a fork of EhViewer-Overhauled, which is itself part of a long lineage: the licence file carries copyright lines from Hippo Seven, NekoInverter, Tarsin Norbin and Foolbar, spanning 2014 through 2024. That chain matters when you are choosing between the several projects that all call themselves EhViewer.

The audience is narrow and specific. You need an Android device, you need an account on the site the client talks to, and you want the interface to follow the Material Design 3 system, including Dynamic Color, which derives the app palette from the user's wallpaper on supported Android versions. If you want a browser tab, this is not that. One of the recurring search questions is whether EhViewer is an online website; it is not, and the README's Download section makes the distribution model clear by pointing at GitHub Releases.

The topics on the repository (android, app, e-hentai, ehviewer, jetpack-compose, kotlin, material-design) match the README's own framing. Nothing in the README suggests a server component or a hosted offering.

The mechanism: Compose UI, Ktor, Coil and a Rust toolchain in the build

The README's Thanks section is the most useful architectural document in the repository. It lists the libraries the project depends on: Arrow, AOSP and AndroidX, Kotlin and KotlinX, Material Icons, Ktor, Coil, Compose Destinations and libarchive. Read together with the top-level directory listing, that gives a reasonably clear picture of how the app is put together.

Ktor is the HTTP client, so network requests to the site go through a Kotlin-native stack rather than Retrofit or OkHttp directly. Coil handles image loading, which is the part of an image-browsing client that determines how the gallery grid feels. Compose Destinations supplies type-safe navigation between screens in a Jetpack Compose app. Arrow brings functional programming primitives into the Kotlin code. libarchive is a C library, and it is the one dependency in the list that is not Kotlin or Android, which suggests archive handling (the format galleries are packaged in) is delegated to native code rather than reimplemented.

The repository layout supports this reading. There is an app/ module, a core/ module, a benchmark/ module, and a build-logic/ directory for convention plugins, which is the standard shape of a multi-module Gradle Android project. There is also a rust-toolchain.toml at the top level, and the primary language is listed as Kotlin. A Rust toolchain file in a Kotlin repository usually means some component is built from Rust source, most plausibly the libarchive binding. The README does not explain this, so treat it as an inference from the file list rather than a documented fact.

The build also carries a .java-version file, which pins the JDK the project expects. If you build from source, that file is the authority on which Java version to use, not whatever is on your machine.

Installing the FooIbar/EhViewer APK and signing in

The README does not give command-line install steps. It gives a download table and a link to GitHub Releases, which is where the APKs live. The table defines two flavors and their minimum Android versions:

Flavor  | Minimum Android Version | Notes
Default | 8.0                     | Full support
Nougat  | 7.0                     | Limited support, no guarantees

So the first decision is which asset to download. The Default flavor requires Android 8.0 and is described as full support. The Nougat flavor runs on Android 7.0 but the README itself says limited support and no guarantees. If your device is on 8.0 or later, take Default.

There is no package manager command to run, because the project is not distributed through a store. The README's download section links to the Releases page, and the badge above it points at the same place. On the device, you install the APK file through the system installer, which means enabling installation from unknown sources for whichever app you use to open the file. That is an Android setting, not a project setting, and the README does not walk through it.

Once installed, the app needs credentials for the site it connects to. Search data shows people asking about "ehviewer login" and "ehviewer web login", and the repository topics include e-hentai. The README does not document the login flow, so the honest answer is that the README is silent on it. What can be said is that the client has a WebView-based path, since "ehviewer webview" is a phrase people search for, and a WebView is the usual way an Android client handles a site's own authentication page.

Building from source is a different route. The repository is a Gradle project: settings.gradle.kts, build.gradle.kts, gradle.properties, a gradle/ wrapper directory, and gradlew plus gradlew.bat at the top level. The README does not name a Gradle task or a flavor dimension, and the material contains no build command to copy, so a source build means reading the app module's build file and the .java-version and rust-toolchain.toml requirements yourself.

Where this fork stops being the right tool

The clearest limitation is platform. There is no desktop version. "EhViewer有pc版吗" is a real question people ask, and the answer from this repository is no: the topics are android and app, the download table is about Android versions, and the build produces an Android application. If you want to browse from a desktop, this project does not serve you at all.

The second limitation is the Nougat flavor's own disclaimer. The README's table says limited support, no guarantees for Android 7.0. That is unusually blunt for a project README, and it should be read as a real boundary rather than boilerplate. If you are on Android 7.0, you are on a path the maintainer is not committing to.

Third, the distribution model has a cost. There is no store listing in the README, so updates come from GitHub Releases. The most recent release listed is 1.14.6 from 2025-12-17, preceded by 1.14.5 on 2025-10-19 and 1.14.4 on 2025-10-12. Anyone who wants an app that updates itself through a store will find this manual. "ehviewer update" is a phrase in the search data, which suggests this friction is felt.

Fourth, the search question "为什么我的EhViewer解析失败" (why does my EhViewer fail to parse) points at a class of failure the README does not address. A client that depends on a remote site's responses breaks when those responses change. The README has no troubleshooting section, no error catalogue, and no statement about what the app does when a response does not match expectations. That silence is itself information: there is no documented recovery path, and no documented rollback either.

How it differs from the mainline EhViewer and from a browser

The most direct alternative is the project this one forked from, EhViewer-Overhauled, and behind that the original EhViewer. The README states the fork relationship explicitly and links to the upstream repository. The difference the README claims is Material Design 3 plus Dynamic Color, and the repository topics add jetpack-compose. That is the substance of the fork: the interface layer is rebuilt on Compose with the newer Material specification, while the underlying job of talking to the site stays broadly the same across the family.

That means the choice between the forks is mostly about interface and maintenance, not about capability. If you are already on EhViewer-Overhauled and it works for you, moving to this fork buys you the Compose UI and Dynamic Color and costs you a migration of settings and any local state. The README does not describe an import path between the two, so assume a fresh setup.

The other alternative is the site in a mobile browser. A browser needs no APK, no unknown-sources permission, and no manual update cycle. What it does not give you is a native gallery grid, Coil-managed image loading, or an interface built to the Material Design 3 spec. Whether that trade is worth it depends on how much time you spend in the app. For occasional browsing, the browser wins on maintenance cost alone.

Licence, source builds and what an upgrade costs

The project is GPL-3.0. The licence text in the README is the standard GPLv3 notice, with the copyright lines listed above and the usual warranty disclaimer. For someone installing the APK, the practical consequence is close to zero. For someone distributing a modified build, GPL-3.0 carries obligations about source availability and licence preservation that you should read in the LICENSE file rather than take from an article. This is not legal advice, and the LICENSE file at the repository root is the document that governs.

The NOTICE file at the top level is worth opening if you plan to redistribute, since it typically collects attribution for bundled components. The README's Thanks section names the libraries but does not state their licences, so the NOTICE file is the place to check.

Upgrade cost splits by how you got the app. If you installed an APK, upgrading means downloading the next release asset and installing over the existing app. The release history listed for the repository shows releases in October and December 2025, and nothing in the README promises a cadence. If you build from source, every upgrade means re-running the Gradle build, and you inherit the toolchain requirements from .java-version and rust-toolchain.toml. The Rust toolchain file is the one that will surprise people: a Kotlin Android project that also needs a Rust toolchain installed is a heavier build environment than most contributors expect, and the README does not explain why it is there.

The repository also carries a renovate.json, which indicates dependency updates are automated. That is a maintenance signal, not a quality guarantee, and it says nothing about whether a given release will work on your device.

Editorial conclusion

Adopt FooIbar/EhViewer if you are on Android 8.0 or newer, you want a Compose-based E-Hentai client with Material Design 3 and Dynamic Color, and you accept that updates arrive as APKs from GitHub Releases rather than a store. Do not adopt it if you need a desktop client, if you are on Android 7.0 and expect the Nougat flavor to behave like the default one, or if a GPL-3.0 obligation on a distributed fork is a problem for your use. Before installing, verify two things: that the release asset matches the flavor you need, and that the README's minimum-version table still lists the Android version you are running.

Frequently asked questions

Official sources

1. FooIbar/EhViewer on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases