📜 ⬆️ ⬇️

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 (ED2K) protocol has long been discontinued, but this is not entirely true.

Immediately make a reservation - this is not about changes in the eMule program and not even about the mode of this program, but about an independent project. Why eMule - because this well-known client name has become a household name and is usually mentioned when talking about file sharing using the ED2K protocol.
')
Details below.

Foreword


A few years ago, I participated in the development of a client for ED2K networks (eDonkey2000). This network almost forgotten on the territory of Russia is still quite popular in Europe. The best-known customers are eMule and its cross-platform aMule mod.

The eDonkey protocol and the modified eMule client are used on the local Internet provider’s network to exchange files within the network. The requirements were the following: adding support for torrents, cross-platform Linux, Windows and Mac, and improved 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 divide the code into the core, providing interaction with the network and interface. For the library, the well-known libtorrent-rasterbar served as a prototype, for qBittorrent for gui, especially since he already used the libtorrent-rasterbar. Thus, the project was implemented using C ++, boost and Qt. As a transport libtorrent-rasterbar and libed2k, gui are a recycled qBittorrent.

For quite a long time, I was considering options for a mobile application. This could be a QtQuick application, a Java application with a library call via JNI, or simply a native application. Since I didn’t have any development experience for mobile platforms at all, but I had Qt experience, the first option was chosen. I was not going to port the application itself, but its light version does not contain torrents. Looking ahead, I will say that in the end everything was rewritten in Java and the native application was made.

Cross compilation library


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

To build libed2k you need a compiled boost, from which I started.

In the process of finding a suitable solution, the options were enumerated using the original NDK and using CrystaxNDK. Crystax possessed the presence of an already assembled boost - the assembly of the boost seemed to me one of the most difficult tasks. The test application was assembled pretty quickly, but upon launching it fell. It turned out that the guys who had not yet implemented the system functions were replaced by the developers with a kind of stub, when called, the application receives a signal and drops. From my point of view, not the best option - the application is going, but does not work. I could not defeat the reassembly of the Crystax, so I had to turn to the original NDK.

Build boost


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

Actually, this is almost all - it remains to follow the instructions from Boost-for-Android.

Build a library


The library uses CMake and that was the problem. In general, CMake is available in the android studio, but I knew nothing about it and always ran the build from the console. Here the android-cmake project helped me.

For support, it was necessary to add the Android.cmake file, which is almost identical to the Linux configuration and use find_host_package instead of find_package, adding the following stub:

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

The build process is described in more detail here libed2k .

GUI build


This part had to be done practically from scratch. To reuse some models and work with the kernel. Looking at code examples in QML, etc. I came to the conclusion that writing from scratch is not an option, we must look for ways to simplify development. I had this method using qml-material . Immediately there are the main elements of the mobile application interface made at a high artistic level. It is all set up simply - either you can use the one recommended by the authors, or simply download and decompose everything into folders in your Qt installation with your hands.
Then everything goes along a more or less standard path - specify the path to the pre-assembled libraries and run the build. Build did 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 advertising in an application.

I will describe the account verification process. AdMob has a convenient withdrawal; 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 in the mail. There are three attempts with an interval of about a month. I waited longer, afraid to spend all attempts in vain, but so did not wait. However, everything ended well, which is why I decided to mention the advertisement. You do not have to wait for postcards more than the interval offered by the admob - after all the attempts have been exhausted and the deadline has come out, you will be able to verify simply by sending a scan of the document to them by mail. In the scan, you can add watermark - 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 such as Amazon unfortunately did not stand close by.

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 true, especially when publishing updates - you just need to prepare a description and screenshots. However, before clicking the “publish” button, it is important to read the publication rules from Google, otherwise there is a considerable likelihood to read them after receiving the letter about blocking the application. Read the documentation was lazy and I studied it after the lock. Google does not send an exact description of the violation - just a section or sections of the rules that were violated, you are asked to determine for yourself what exactly the publication did not pass the test, 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. It helps to avoid negative assessments at the very beginning.

Almost my only PR campaign is an announcement on the official eMule forum. I did not make any further promotion attempts. Nevertheless, the number of installations gradually grew. After the first update, the program was banned by Google Play. Yes, it happens the same way - you release an update and get an email about blocking the application. The reason for blocking is impersonation of another person, or copyright infringement. Attempt to appeal did not bring results. The screenshots of the program with Roxette download and the program icon itself, assembled from pieces of the Android logo, came under suspicion. I was not very upset, moreover, this ban 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 will say that maybe the problem was in the title with the mention “donkey”, because the following application with the name jDonkey was also banned. During the year, updates were released, support for Kademlia was added.

The number of installations has grown over the course of a year, but is now beginning to fall gradually. Perhaps this is due to the transition of users to the Java version or to the general outflow of users from the ED2K network. In parallel, published a paid version without ads - quite unexpectedly, but it was sold.

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

Conclusion


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

Links


Source: https://habr.com/ru/post/323834/


All Articles