Open-source project
EhViewer-NekoInverter/EhViewer avatar
EhViewer-NekoInverter/EhViewer

EhViewer (NekoInverter fork): a Material Design 2 Android client, downloaded from GitHub Releases

🥥 A fork of EhViewer, feature requests are not accepted. Forked from https://gitlab.com/NekoInverter/EhViewer

3,680 stars168 forksKotlinGPL-3.0

At a glance

What is it?
This fork of EhViewer keeps the classic Material Design 2 interface, ships APKs through GitHub Releases, and states plainly that feature requests are not accepted. It is a personal-use Android client, not a maintained platform.
Who is it for?
Adopt this fork if you want the classic Material Design 2 EhViewer interface on Android 9.0 or newer and you are comfortable downloading APKs from GitHub Releases, with the understanding that the README says feature requests are not accepted. Do not adopt it if you need Material Design 3, animated WebP on Android 6.0 to 8.1, or a project that responds to feature requests; EhViewer-Overhauled is the fork the README points to for MD3.
Can I use it commercially?
Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
Is it still maintained?
Yes. The repository last received commits 65 days ago.
What is it written in?
Mainly Kotlin, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What this fork is, and who it is actually for

EhViewer-NekoInverter is a fork of EhViewer, an Android client for browsing e-hentai and exhentai. The repository is written in Kotlin, licensed GPL-3.0, and its README opens with a single design statement: it is an EhViewer fork with classic Material Design 2 style. That sentence is the whole pitch. If you are choosing between EhViewer forks, the interface generation is the deciding variable here, not a feature list.

The README is equally direct about scope. It says the fork is for personal use and does not accept feature requests. That is not modesty, it is a governance statement: issues about common usage are redirected to a single Q&A thread, issue #18. Treat the repository as a maintained artifact rather than a product with a roadmap. The last push was on 2026-07-28, and the most recent tagged release is v1.8.13 from 2026-03-19, with v1.8.12 and v1.8.11 before it in December 2025. Those dates tell you the code moves, but the README tells you the maintainers are not taking your ideas.

Who is it for? Android users who already know what EhViewer is, who preferred the older Material Design 2 layout, and who are willing to sideload an APK. If you have never used an EhViewer client and you want a supported, feature-responsive project, this fork is the wrong entry point.

How the client is put together: Kotlin, Ktor, Jsoup, Coil

The README's Thanks section doubles as a dependency inventory, and it is the clearest window into the architecture. Networking runs on Ktor and OkHttp. HTML parsing uses Jsoup, which implies the client is reading and extracting from server-rendered pages rather than consuming a documented JSON API. Image loading is Coil. Archive handling uses Libarchive, which matters for downloaded galleries. The UI is built on MDC-Android (Material Components for Android) plus AOSP and AndroidX, and there is FullDraggableDrawer for the drawer behaviour and RikkaX from RikkaApps.

The data flow that follows from that list is conventional for this class of app: the client authenticates, fetches listing and detail pages, parses them with Jsoup, renders thumbnails and pages through Coil, and stores downloaded content, with Libarchive unpacking archives. The presence of Jsoup rather than a typed API client is the important design fact. A scraper-shaped client is coupled to the server's HTML, so a markup change on the server side can break parsing in ways an API client would not experience. That is a structural fragility, not a criticism of this particular fork.

Tag translation is pulled from the EhTagTranslation Database, and the README credits a Japanese translator. Localisation and tag data are therefore external inputs, not something baked into the APK at build time in a way the README describes.

The repository layout is a standard single-module Gradle Android project: app/, build.gradle.kts, settings.gradle.kts, gradle/, gradlew and gradlew.bat, plus docs/ and .github/ for the CI workflow referenced in the badge.

Installing the APK and getting to a first gallery

There is no package-manager install path here. The README sends you to GitHub Releases for the release build. Download the APK for the latest tag, which at the time of writing is v1.8.13, and open it on the device. Because it is distributed outside a store, Android will ask you to allow installation from the source you used.

The README gives one hard compatibility constraint, in a two-row table. Android 6.0 to 8.1 has no support for animated WebP. Android 9.0 and above has full support. The repository ships a Gradle wrapper, so the documented build entry point is the wrapper script at the repository root:

bash
./gradlew

If the release build has unresolved issues, the README offers a second channel: the CI workflow on the master branch, downloadable from GitHub Actions. That route requires a GitHub account login, which the README states explicitly. It is a build artifact, not a release, so expect it to be less settled than a tagged APK.

Once installed, the first real use is signing in, because the client browses account-scoped content. The README does not document a login walkthrough; it points common usage questions at issue #18. So the honest first-run sequence is: install the APK, open the app, sign in with the account the client expects, and use issue #18 as your reference when a step does not match what you see.

The Material Design 2 choice is a real trade-off, not a preference toggle

The single most consequential thing about this fork is that it is built on MDC-Android and describes itself as classic Material Design 2 style. That is a deliberate divergence from the direction the upstream EhViewer ecosystem moved. The README does not hedge: if you prefer Material Design 3, it tells you to consider EhViewer-Overhauled instead. A fork that names its own replacement in the first screen of documentation is being clear about its audience.

The cost is that you are opting out of the newer design system, its components and whatever accessibility and theming work comes with it. You are also opting into a project that has declared it will not take feature requests. Those two facts compound: you get a stable interface you already like, and you give up the expectation that it will grow in the direction you want.

The Android version table is the second constraint and it is easy to skim past. On Android 6.0 through 8.1 the app cannot display animated WebP. If your library or your browsing habits lean on animated content, that is a functional gap, not a cosmetic one, and it is the difference between the two rows of the table.

What the documentation does not cover

The README is short by design. It has sections for description, download, screenshot, thanks and license, and nothing else. There is no changelog in the README, no migration notes between v1.8.11, v1.8.12 and v1.8.13, and no description of what changed in any release. If you are upgrading across several versions, the release pages are your only source, and the README does not tell you how to interpret them.

There is no documented rollback path. The README does not say whether you can downgrade an installed APK to an earlier release, whether app data survives a downgrade, or how to export anything before you try. That silence matters more than usual for an app that stores downloads and account state.

There is also no build documentation beyond the presence of the Gradle wrapper, no signing instructions, and no statement about which Gradle or JDK version the project expects. The CI workflow file exists at .github/workflows/ci.yml, and the README links to it for CI builds, but the README itself does not walk through reproducing that environment.

Finally, the README does not document the login flow, despite login being the first thing a new user must do. It defers to issue #18 for common usage problems, which is a reasonable choice for a personal-use fork but a poor substitute for documentation if you are trying to evaluate the app before installing it.

EhViewer-Overhauled and the other forks

The README names the alternative itself: EhViewer-Overhauled, at github.com/FooIbar/EhViewer, recommended for people who prefer Material Design 3. The difference is not a feature checklist, it is the design system the UI is built on. This fork sits on MDC-Android and classic Material Design 2; Overhauled targets the newer generation. Everything else, the Kotlin codebase, the GPL-3.0 licence, the Android client role, is shared lineage, since both descend from the same EhViewer family.

That shared lineage is why the choice comes down to interface generation and project posture. This fork states it does not accept feature requests. If you want a project that entertains changes, the README's own pointer is the place to look. If you want the older layout preserved and you accept the frozen scope, this is the fork that says so out loud.

There is a third consideration the README surfaces indirectly: distribution. This fork distributes through GitHub Releases and, for CI builds, GitHub Actions behind a login. Where you get the APK, and whether you are willing to install from there, is part of the decision, not a detail after it.

Licence, upgrade cost and what maintenance looks like here

The licence is GPL-3.0. The README carries the standard grant and disclaimer, with copyright lines for Hippo Seven (2014-2019), NekoInverter (2020-2022) and Moedog (2022-2025). Because it is GPL-3.0, if you redistribute the app or a modified version, the licence obligations travel with it. If you only install and use the APK, that is a different situation. This is a description of what the licence text says, not legal advice; read LICENSE and NOTICE in the repository if redistribution is on your agenda.

Upgrade cost is low in operational terms and high in uncertainty. There is no store to push updates, so you check GitHub Releases yourself. The README gives no changelog, no downgrade guidance and no data-migration notes, so an upgrade is an act of faith that the new tag behaves like the old one. The release cadence visible in the repository is uneven: v1.8.11 on 2025-12-15, v1.8.12 on 2025-12-26, then v1.8.13 on 2026-03-19. Gaps of that length mean you should not expect rapid fixes.

On maintenance, the facts are the facts. The repository is not archived, and the last push was on 2026-07-28. That is recent enough that the project is not abandoned, but the README's own statement that feature requests are not accepted means activity should not be read as responsiveness. The Q&A thread at issue #18 is the documented support channel, and it is a thread, not a support desk.

Editorial conclusion

Adopt this fork if you want the classic Material Design 2 EhViewer interface on Android 9.0 or newer and you are comfortable downloading APKs from GitHub Releases, with the understanding that the README says feature requests are not accepted. Do not adopt it if you need Material Design 3, animated WebP on Android 6.0 to 8.1, or a project that responds to feature requests; EhViewer-Overhauled is the fork the README points to for MD3. Before installing, verify the release page carries a build newer than v1.8.13 from 2026-03-19, confirm your Android version against the two-row support table, and read issue #18 if you hit a common usage problem.

Frequently asked questions

Does EhViewer require an account?

The README does not document the login flow, and it directs common usage questions to issue #18. What can be said from the repository is that signing in is part of first use, since the client browses account-scoped content, but the README gives no step-by-step account instructions.

What are the alternatives to EhViewer?

The README names one directly: EhViewer-Overhauled, at github.com/FooIbar/EhViewer, recommended for people who prefer Material Design 3. This fork keeps the classic Material Design 2 style, so the difference between the two is the design system the interface is built on.

What is an EH viewer?

In this repository, EhViewer is an Android client for browsing e-hentai and exhentai, written in Kotlin and licensed GPL-3.0. This particular project is a fork of EhViewer that keeps the classic Material Design 2 style.

How do I use EhViewer-NekoInverter?

Install the APK from GitHub Releases, then sign in when the app opens. The README does not provide a usage walkthrough and points common usage questions at issue #18, so that thread is the documented reference when a step does not match what you see.

Official sources

  1. EhViewer-NekoInverter/EhViewer on GitHub
  2. Issues
  3. License: GPL-3.0
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/ehviewer-nekoinverter-ehviewer.svg)](https://hysenlabs.com/projects/ehviewer-nekoinverter-ehviewer)