Eliminating Ministro but still avoiding duplicate libraries.

[/#!/JoePea]

I have a couple of ideas that eliminate having to have Ministro installed while still avoiding duplicate Qt libraries on an Android device.

My first idea:
An easier solution would be for Necessitas apps to download missing Qt libraries and store them in a common folder on the "external storage" that all Google-Play-enabled phones ship with. External storage is shared with all applications, so all Necessitas apps could look in one central location for library files. When a Qt library file is needed by a Necessitas app, it should be checked for an md5 or sha1 sum (or etc) to be sure another malicious app has not tampered with the files. If the validity check fails for a file, then the Necessitas app would simply download the file again and replace the file in question. All Necessitas apps can check for Qt libraries in a single central location on the phone.

But what if no "external storage" is available?

We could use the data/ folder for each Necessitas app to store Qt files, but having multiple Necessitas apps would begin wasting phone space with duplicate Qt libraries in each app's data folder.

What can we do in this case to avoid duplicate Qt library files?

My second idea:
A more difficult but much better solution would be to use Context.sendOrderedBroadcast (a broadcasts that expects a message in return) and android.content.BroadcastReceiver (listens for a broadcast). Every Necessitas app would send an ordered broadcast during it's first run containing the name of needed libraries (comma separated) to determine if any other Necessitas apps are installed and to determine if those apps already have the needed libraries. If a Necessitas app already has a library that is requested when it receives the broadcast, a result sent back to the broadcasting origin app contain the locations of the Qt libraries stored by that app.

Pretend there are three Necessitas apps in Google Play called X, Y, and Z. If you install Y (the first Necessitas app on your device), it will send a broadcast when you run it for the first time but will not get a response. Y app will then download the necessary Qt libraries into it's data/ folder on the first run. Now, you install the Z app next. The Z app will send a first-run broadcast that all Necessitas apps listen for. The broadcast from Z contains a request for the Qt libraries that it needs. If another Necessitas app has the required Qt libraries, it will return a message saying which library it already has available. For example, Y has a library that Z needs, so Z will not have to download that library because Y will share it with Z (Y has given the library world-readable permissions). However, Y doesn't have one of the library files that Z needs so Z will also download a new library file. So now, Y has a library file, and Z has another one. Now we install the X app. X app sends a first-run broadcast to determine which other Necessitas apps already have the libraries X needs. In our example, Y and Z acknowledge they have the needed files for X, so X uses those files. The X app might also need to download more libraries. Now we delete the Y app. At this point no other Necessitas app has the library file that Y had. Next we run the X app and it detects that the library file provided by Y is now missing. The X app will send a new broadcast to see if any other apps have the needed file. No other apps have the file that Y had so X app will download the needed library file and be the new carrier of that file. Now when we run the Z app, it will also detect that the file from Y is gone and it will send a new broadcast. The X app will respond and Z will take note that X is the new carrier for the library file (a matter of milliseconds) and Z will look for the world-readable file in the data directory of X app from now on, until X is uninstalled. And so this loop continues indefinitely. No matter how many Necessitas apps you install, you will not have duplicate libraries. We would still need file-validity checks (e.g. md5, sha1, etc) because a malicious app could pretend to be a Necessitas app and could respond to broadcasts with a malicious Qt library file. Overall this would be more secure than using external storage because apps would not have write permissions to any of the library files in the data folders like they would with external storage and users would not arbitrarily remove the library files. A Necessitas app could blacklist apps that provide tampered library files during a broadcast and try the broadcast again.

Eliminating Ministro would provide a smoother experience for users so they only need to install a single app (their app) instead of two apps (their app + Ministro) when they use a Qt-powered app for the first time.

What do you think about my ideas (particularly the second one)?

/#!/JoePea

[trusktr]

If done properly, any number of Necessitas apps could be installed and one would never have to worry about extra apps or duplicate Qt libraries or anything. It'd be invisible to the end user, unlike Ministro.

[BogDan Vatra]

Hi,

What makes you think that checking the md5 to a file and loading it
is an atomic operation? Even more, checking a MD5 to a file is a very
expensive operation and it will take seconds until your application
will start.
Your first idea is not possible on all devices because on most of
them the android os doesn't allow to load .so libs from an insecure
locations (e.g. sdcard).
IMHO the second one, is even worse, because it adds another one,
most/some of the Qt application that will respond to your broadcast,
will use this occasion to display their ads. if you have a few this
kind of these apps installed, you'll end up with your device screen
full of ads.

Do you prefer to wait a few seconds to check all the md5s and then
to pray that nobody replaces it meanwhile and to display other apps
ads, every time when your application starts, instead to install
Ministro once? Do you think is better for users?

It took me +6 months to invent/design and code Ministro (yes, I'm
that stupid !), I've checked all these ideas, and the most secured and
the less annoying was Ministro.

As I said before, some of you blame Ministro because their apps are
not downloaded. Installing Ministro is pretty straightforward. The
users uninstall these apps not because they can't install Ministro,
but because these apps are not addictive enough.

Cheers,
BogDan.


2013/1/14 trusktr <tru...@gmail.com>:

[Enrico Miglino]

Hi Bog and all :)

As you know I will write rarely, but always read. This thread of discussions abut ministro has long long long ... long history ! What it seems that developers does not undestand, is that the Android-ministro still exist as a default embedded stuff - or similar but with the same functional effect - in the Symbian devices, or harmattan, of Maemo or whatever else. The concept is - just as it does happens on the desktops too, does now matter if windows, mac or linux - that Qt NEEDS its own libraries. 

Ignoring the discussion about the static libraries that are out of the concept, not handful, not useful and part of a different license - ministro on Android is the Qt libraries on Symbian and all the other devices that support something like this.

I think that the concept should be moved in a slight different direction: what the developers should answers is something like <<How much you will like a cheap, high quality, high profiled smartphone that will include symbian as a native library>> ???

I hope that someone will give a answer to this question anyway because there is a reason that I have put it here. I will explain more in next messages, if this maybe interesting.

Cheers, Enrico