eMule on Android

eMule on Android


image

This is a story about how it became possible to download files from the eDonkey network to mobile devices running Android. There is an opinion that the development of clients for the eDonkey protocol (ED2K) has long been discontinued, but this is not entirely true.

I’ll make a reservation right away - this is not about changes in the eMule program and not even about the fashion of this program, but about an independent project. Why eMule - because this well-known name of the client has become a household name and is usually referred to when talking about file sharing using the ED2K protocol.

Details below.

Foreword


Several years ago, I took part in developing a client for ED2K networks (eDonkey2000). This network, almost forgotten in Russia, is still quite popular in Europe. The most famous customers are eMule and its cross-platform mod aMule.

The eDonkey protocol and the modified eMule client are used on the local ISP network to exchange files within the network. The requirements were as follows: adding support for torrents, cross-platform Linux, Windows and Mac, and improving performance. After researching the code of eMule, aMule and some other clients, it became clear that writing everything from scratch is easier than inserting torrents into existing programs. It was decided to split the code into a kernel that provides network connectivity and an interface. For the library, the notorious libtorrent-rasterbar served as a prototype, for the qBittorrent gooey, all the more so since it already used libtorrent-rasterbar. Thus, the project was implemented using C ++, boost and Qt. As the libtorrent-rasterbar and libed2k transport, gui are a redesigned qBittorrent.

For a long time I was thinking about the options for a mobile application. It could be a QtQuick application, a Java application with a library call through JNI, or even just a native application. Since I had no development experience for mobile platforms at all, but had Qt experience, the first option was chosen. I was going to port not the application itself, but its lightweight version not containing torrents. Looking ahead, I’ll say that in the end everything was rewritten in Java and a native application was made.

Cross Compilation Library


A separate libed2k library was created for the original project, which provides work in ED2K networks.

To build libed2k requires compiled boost, from this I started.

In the process of finding a suitable solution, the options were tried using the original NDK and using CrystaxNDK. Crystax had the presence of already assembled boost - assembling the boost seemed to me one of the most difficult tasks. A test application was built quite quickly, but it crashed on launch. It turned out that the developers had replaced the system functions that were not yet implemented by some kind of stub, when called, the application receives a signal and crashes. In my opinion, this is not the best option - the application is being built, but it does not work. I could not defeat the reassembly of Crystax, so I had to turn to the original NDK.

Boost assembly


It turned out to be much easier than I could have imagined. In general, it comes down to running a script. First, check out the Boost-for-Android project . You will need compatible versions of boost and NDK. Download the old version of NDK that quest - below is a link to a description of how to do this.

Actually, that's almost all - it remains to follow the instructions from Boost-for-Android.

Library assembly


The library uses CMake and this was a problem. In general, CMake is available in the android studio, but I did not know anything about it and always started the assembly from the console. Then the android-cmake project helped me .

For support, I needed to add the Android.cmake file, which is almost identical to the config on Linux and use find_host_package instead of find_package, adding such a stub:

if(NOTCOMMAND find_host_package)
  macro(find_host_package)
    find_package(${ARGN})
  endmacro()
endif()

The build process is described in more detail here libed2k .

GUI assembly


This part had to be done from scratch. It turned out to reuse some models and work with the kernel. By looking at QML code examples, etc. I came to the conclusion that writing from scratch is not an option, we must look for ways to simplify development. For me, this method was to use qml-material . Immediately there are basic elements of the mobile application interface made at a high artistic level. It’s easy to install - either you can manage to use the one recommended by the authors, or just download and put everything into folders in your Qt installation by hand.
Further, everything goes along a more or less standard path - specify the path to the pre-assembled libraries and start the assembly. The assembly was made static to simplify deployment.

Advertising


Advertising bringing even a small profit motivates to continue development and make improvements. I will not dwell in detail - a simple Google search according to Qt AdMob provides links to articles that I used when embedding ads in the application.

I will describe the account verification process. AdMob has a convenient withdrawal of funds to the account; the threshold from which you can withdraw funds starts at $ 100. But there is one obstacle - the account must be verified. Verification occurs by sending a real paper card with a code by mail. There are three attempts at intervals of about a month. I waited longer, being afraid to spend all attempts in vain, but did not wait for anything. However, it all ended well, which is why I decided to mention the advertisement. No need to wait for postcards over the interval offered by the admob - after all attempts have been exhausted and the check period has expired, you will have the opportunity to verify simply by sending a scan of the document to them in the mail. You can add watermarks to the scan - it will still be accepted.

Publication


A few words about publishing on Google Play. I describe on the example of Google Play, because now it is an unconditional monopolist. The closest competitors like Amazon, unfortunately, were not around.

So, the application is ready, the account is paid, the package is assembled - you can publish. For me, the publication was presented as a kind of simple, automatic stage, which would end as if by itself. Fortunately, this is basically the case, especially when publishing updates - you just need to prepare a description and screenshots. However, before you click the publish button, it’s important to read Google’s publishing rules, otherwise there’s a good chance of reading them after you receive the letter about blocking the application. Read the documentation was too lazy and I studied it after blocking. Google does not send an exact description of the violation - just the section or sections of the rules that were violated, you are asked to determine for yourself that the publication did not pass the verification, but this is not so simple.

And finally - use alpha and beta versions, it is very convenient. Everything is the same as with the release, but you can configure accessibility and users will not be able to publicly evaluate the application. Helps to avoid negative ratings at the very beginning.

Almost my only PR action is the announcement on the official eMule forum. I did not make any promotion attempts anymore. Nevertheless, the number of installations gradually increased. After the first update, the program banned Google Play. Yes, this also happens - you release the update and receive a letter about blocking the application. The reason for blocking is impersonation of another person, or copyright infringement. The appeal attempt failed. The screenshots of the program with the Roxette download and the program icon itself, assembled from pieces of the Android logo, were suspected. I was not very upset, moreover, this ban just encouraged me to add ads, draw icons and some other improvements. Re-publishing the application with a new icon and edited screenshots, as well as a new name, solved the problem. Looking ahead, I’ll say that maybe the problem was in the name mentioning “donkey” because the next application named jDonkey was banned as well. Updates were released throughout the year, support for Kademlia was added.

The number of installations grew during the year, but now it is beginning to gradually decline. Perhaps this is due to the transition of users to a version in Java or a general outflow of users from the ED2K network. In parallel, I published a paid version without ads - quite unexpectedly, but it was on sale.

In general, the application has shown itself to be quite stable.

Conclusion


Actually, this is all about a C ++ application on Android. The Qt / C ++ bundle works pretty well on Android. Using qml-material components, you can quickly build beautiful interfaces. Among the shortcomings is a long loading of the application and more complex integration with the system. As I mentioned above, the application was rewritten in Java and now only this option is being developed. If the article is of interest, I will write more about the internal device of the eDonkey protocol, what is Kademlia (DHT) and how it works.

References



Also popular now: