Goal: Explore the possibility of adding Kumo to IzzyOnDroid

[nubesurrealista]

Objectives:

• The app must be sufficiently distinguishable from Mihon and Kahon.
• It must be FOSS.
• It must meet Izzy's inclusion criteria.

Once all of this has been achieved, submit a request for inclusion.

[nubesurrealista]

@IzzySoft Sorry for the tag, but I wanted to ask about the inclusion requirements and what my app is currently missing in order to meet them.

This is mainly a personal and learning project, but I want to take it a little more seriously. Compared to Mihon, all the new features in my app are cherry-picked (from projects with the same license, Mihon forks, and giving authorship in the commits). Is that a problem? However, I have original features such as new themes.

So, this isn't something immediate, it's a future goal, I just want to get an idea of what I need to do.

[nubesurrealista]

This app exists for two reasons: learning and personal use. I like Mihon and I like Kahon, but I don't like that Mihon lacks certain features or that it has telemetry, and I don't like that Kahon includes features that break my user experience.

So, instead of wasting time on both projects (which I respect), I preferred to make my own app, with Kahon commits that I consider necessary but without breaking my user experience. Why a fork of Mihon and not a direct fork of Kahon? I simply want to keep up with the main source. Although Kahon is my inspiration and the reason why this exists, I prefer to rely on a stable base.

[IzzySoft]

First of all, I cannot even tell what it is about: Kumo is like Mihon with features from Kahon but also adopts from Kamikko… What are they all about? Following the link to Kahon does not alight me either: it's a fork of Mihon, but with different features.

No plan what all those apps do – apart from obviously being connected, and having some things in common 🙈 Thus, the first thing would be a proper description what the app is about – for those not knowing either of its siblings. Some screenshots would help, too 😉

Checking releases: we have a per-app size limit of 30 MB currently, so the APK is already slightly beyond that. Sent it through our scanners nevertheless: looks fine, not a single warning even. Guess we can do something about the size, e.g. by using a single ABI APK (just with arm64), that would bring it down to below 28 MB or so I guess.

As for description and graphics, you might wish to take a look at the IzzyOnDroid Fastlane Documentation – with those structures in place, you could maintain how your app is presented, and we would fetch changes whenever a new release is being fetched.

PS: OK, Mihon obviously has something to do with Manga, so it's most likely a Manga reader. Needed 3 hops to figure 🙈 Well, not an area I visit often. Not due to dislike, more due to lack of time…

[nubesurrealista]

@IzzySoft

First of all, I cannot even tell what it is about: Kumo is like Mihon with features from Kahon but also adopts from Kamikko… What are they all about? Following the link to Kahon does not alight me either: it's a fork of Mihon, but with different features.

Um, yes, I think I may have made a mistake by not specifying much about the app and focusing on “It's a fork of... with patches from...”. I guess if the user doesn't know what I'm talking about, they won't understand anything.

So, yes, it is a manga reader, it does not host anything, by default it is somewhat useless or for local use, Mihon has a feature of external extensions repositories, which allow the user to access content. These extensions have nothing to do with Mihon or its forks, it is something that the user must add if they want to, so the app does not host anything or refer to any repository by default.

However, the original app, Mihon, does depend on some proprietary things like Google Firebase and that kind of analytics. So, Kahon, the fork, is a free fork that removes telemetry and removes some limitations on the extension system.

Kumo takes this approach from Kahon and its commits to remove all telemetry from the app, but I don't remove the limitations on extensions because without them, some of them don't work properly. But Kahon is very basic, it removes limitations and telemetry, but apart from that, it's just a freer Mihon. And that's fine, but I wanted more, so I've taken changes from other forks and added a couple of themes that neither Mihon nor any other fork has.

I don't have a huge list of changes because I don't have the knowledge to implement them, so I'm taking it slowly, looking at the code, reading, bringing in small things, etc.

But if Kahon is a freer Mihon with a couple of extra features without being that different and can be on F-droid, then I think that in the future, I could also be on Izzy.

Checking releases: we have a per-app size limit of 30 MB currently, so the APK is already slightly beyond that. Sent it through our scanners nevertheless: looks fine, not a single warning even. Guess we can do something about the size, e.g. by using a single ABI APK (just with arm64), that would bring it down to below 28 MB or so I guess.

Oh, I didn't know that. I'll try to find a way to reduce the size if possible. If not, I can go back to the two apk system, 32-bit and 64-bit. Since the app weighs about 21-22 MB depending on the architecture.

As for description and graphics, you might wish to take a look at the IzzyOnDroid Fastlane Documentation – with those structures in place, you could maintain how your app is presented, and we would fetch changes whenever a new release is being fetched.

Thanks for your reply. I'll definitely read more and try to do what's necessary to join.

This was just to “test the waters.” I didn't think I'd get a reply considering how small this is. I think I can resolve this and revisit this issue soon.

Again, thank you very much for the reply!

[IzzySoft]

Um, yes, I think I may have made a mistake by not specifying much about the app and focusing on “It's a fork of... with patches from...”. I guess if the user doesn't know what I'm talking about, they won't understand anything.

That was exactly my problem to begin with indeed 🤣 Apologies if I went to far with showing that, no offense meant – I was just writing my thoughts as they appeared, so you could hopefully follow the windings of my brain there. I guess I succeeded with that 🙈

Thanks for all the details as well. And yes, 22 MB is fully acceptable at IzzyOnDroid. Also, nothing prevents us accepting a Manga reader. Your approach is exactly right: not hasten things, going step by step. This might take a bit longer, but the results will be worth it! Thanks to the slower pace, things can be done much more thoughtfully. Bringing in small things slowly also makes it easier to spot things should they go "wrong".

So feel encouraged on that path – and ring our bell when you think you're ready!

[nubesurrealista]

@IzzySoft

So feel encouraged on that path – and ring our bell when you think you're ready!

So, I spent a few hours reading the documentation and trying to get everything in order, and I think I've got everything ready. There's no new release yet, but the next one will be with split APK, reducing the size to 21-22mb as I mentioned earlier. I used the GitHub action mentioned in the guide and everything seems to be fine.

Izzy only takes releases into account, right? Will there be any problem if I push test pre-releases at some point?

I'm trying to organize the README and those things too. In theory, everything should be in order, but I want to try to accomplish a couple of things first, so thanks for everything, and yes, I'll come back to this issue when I think everything is ready. Maybe soon, idk yet, this is my first app, although it is a fork, it's the first app with which I have been able to play and modify things. So, I'm nervous, I still don't know if this is good enough for other people yet haha.

[IzzySoft]

Izzy only takes releases into account, right? Will there be any problem if I push test pre-releases at some point?

Pre-Releases are skipped unless explicitly enabled at our end (e.g. for apps where we serve beta versions for testers). So no, they should not be an issue.

So, I'm nervous, I still don't know if this is good enough for other people yet haha.

Take your time 😉 No need to rush.

[nubesurrealista]

@IzzySoft I've added a feature that I've been trying to merge for days, and I've made some changes to te repo, such as the fastlane metadata mentioned earlier (I know you're busy, but could you let me know if you think it's okay? Sorry). I use this app often and I like it. I think it's ready to be used for other people. There are no critical bugs or anything like that. There are probably things that could be improved, but it's not broken software :) So, I want to give it a try. Maybe that way I can learn from other people who want to contribute code and the app could improve even more. I think the best way for a project to improve is to receive feedback or suggestions. Sometimes other people see or think of things that you hadn't even considered.

So, if my app meets the requirements and there are no problems, I would like to launch a release tomorrow and start the process. The release will be in two versions, armv7 and armv8. armv8 is 24 MB and armv7 is 21 MB, so I think the size issue is resolved.

[nubesurrealista]

Release it's ready: https://github.com/nubesurrealista/Kumo/releases/latest

[IzzySoft]

Scanner yields some warnings:

• android.permission.REQUEST_INSTALL_PACKAGES
• android.permission.REQUEST_DELETE_PACKAGES
• android.permission.UPDATE_PACKAGES_WITHOUT_USER_ACTION
• android.permission.QUERY_ALL_PACKAGES

What is that for? Sounds like a self-updater (well, could also be something heinously wanting to install stuff behind our backs – but no need to assume things that bad here 🙈) – or something to install extensions. Quoting from the IzzyOnDroid App Inclusion Policy:

• [the app] must not download additional executable binary files (e.g. addons, auto-updates, etc.) without explicit user consent. Consent means it needs to be opt-in (it must not be harder to decline than to accept or presented in a way users are likely to press accept without reading) and structured in a way that clearly explains to users that they’re choosing to bypass the checks performed in this repo if they activate it.

So can you please explain how those permissions are used?

[nubesurrealista]

@IzzySoft As I mentioned before, the app has an extensions feature, which works like this: the user adds an extensions repository (the app does not have one by default, and will not have one), these extensions are apk files that the user must install if they want to. The repo and extensions system handles notifications of extension updates, but the user must decide whether to install them or not.

There is also an auto updater, which I don't think works correctly on my fork. In fact, I want to remove it, but I'm not quite sure how to do that yet. Anyway, I'll check if Kahon made any changes to the manifest to be able to enter F-droid, but as far as I know, there are no changes in that regard.

So: by default, the app cannot install anything beyond an update. The extension system is optional and is completely at the user's discretion. And obviously, I don't want to install weird stuff behind the scenes, and I don't think the original source does either.

If you try the app, this is what you find by default: a local manga reader with synchronization with tracking services (for manga, progress tracking, not the bad kind!) such as Anilist or MyAnimeList. The app doesn't even push the user to add an extension repository, which is what most users of the original app do, but the app itself doesn't encourage you to do so and can work as a local reader.

There is a commit to make the auto update optional. I need to check if I can use it. But I want to remove it. For now, I don't think it works. I guess I should double-check.