Information entropy as an anthropomorphic concept

After this post I wrote a paper on this subject, find it in arxiv.org

One of the most interesting opinions that I have heard about entropy has been formed by E.T. Jaynes and E.P. Wigner (link). According to them, entropy is an anthropomorphic concept in the sense that in a physical system there can be found many thermodynamic systems. The physical system can be examined from many points of view examining different variables each time and calculating entropy differently. In this post and in the paper in arxiv.org that followed it (link), I discuss how I think that we may apply this concept in information entropy, how Shannon’s definition of entropy can fit in Jayne’s and Bank’s opinion. I also present a case in which I have used this combination of ideas in the past in an Android application.
Information entropy has been defined by Claude Shannon (link). It quantifies the amount of information that is transmitted by a channel or more generally the information content that there is in a message M. Message M consists of a set of n symbols, let P(i) be the probability of appearance of any symbol i in M then for all n symbols stands that entropy H = -ΣP(i)logP(i). Probability P(i) equals to the frequency of appearance of i in M.
Let’s generalize this idea. Let S be a set of objects that we may describe their properties using v variables for each one. Let each variable take values from a range [a, b] of discrete values. Now we have a lot of information about S and we can use entropy in order to analyze it. Exactly as Jaynes describes the examination of physical systems we may choose any subset v’ of v in order to examine the information content of S. The choice of v’ depends on how we care to examine S and this provides the anthropomorphic characteristic to our analysis. Using information entropy we can examine the distribution of the properties described by v’ in the objects of S.
For simplicity reasons let us examine S considering two properties for its objects described by variables X and Y. For variable X and for probability P(x) in the appearance of any value x entropy is H(X)=-ΣP(x)logP(x). Same for Y, it stands that H(Y)=-ΣP(y)logP(y). In order to combine these two entropies we have to consider if they are dependent.
As it is known for independent X and Y stands that H(X,Y) = H(X) + H(Y).
For joint probability P(x, y) stands H(X,Y) = -ΣΣ P(x, y)log P(x, y).
For conditional entropy H(X | Y) which stands for the probability P(y, x) when X depends on Y entropy is H(X | Y) = -ΣP(y, x)log(P(y)/P(y, x)).
These considerations about entropy variables are different from the classical definitions of Shannon. Shannon defines conditional probability P(x, y) as the probability of appearance of symbol x which depends on the appearance of symbol y. While the above probabilities consider properties x and y of one discrete object.
Unconsciously I had used in the past all the above for the development of an android application; you may find it here or here. The goal of the application was to rate the strength of passwords for handheld devices. A strong password M must be complex but as we focus in handheld devices the frequency of appearance of each character in M is not the only property we may consider. The user of each device has to change the keyboard appearance of the device in order to write upper case characters, lower case, symbols or numbers. This makes the input of M more complex than in desktop computers and we may consider this property when rating the complexity of M.
The rating of password strength still regards characters of a simple string M but let us look into them as discrete objects of more than one property. Variable X is defined on the set of characters available to the user and P(x) is the frequency of appearance of each character x in M. Variable Y is the property of each symbol of being an upper case character, lower case, symbol or a number. Then P(y) is the probability of y being upper case character, lower case, symbol or number. The two variables are independent; X does not depend on Y. As a result H(X,Y)=H(X) + H(Y). Calculating entropy using the last equation provides a more accurate analysis of the information content of M.
For a more detailed presentation see my paper currently published in arxiv.org.

The illegal and misleading practices of mobogenie.com

Lately I found out that that there is site called mobogenie.com in which two of my Android apps are published. I have not submitted them to this site and I don’t really want them published there. But this didn’t stop them from presenting the apps in the site and putting a download button.
When you press the download button you get an .apk file that it is supposed to be the app that you are seeing in the site it has the same name. In reality it is the “mobogenie” app that tricks you to install it in your device. Then, perhaps you will have the chance do get the app that you actually want. In their disclaimer they admit that they have no control over the app submissions, they don’t really know if the app that you submit is really yours. A few days ago there was a link in the main page with directions on how to claim your own app from mobogenie if you find it there without having submitted it yourself.
Of course I send an e-mail, they respond that they will look at it, two weeks later no answer.
It turns out that they have built a whole market in which is not clear if they have the right to distribute the apps that they distribute. This practice is illegal, at least in my case it is clear in the EULA of my apps that they may be distributed only be authorized distributors; mobogenie is not one of them.
It is also misleading. The app that they let first to download is not the one you asked for.
Most of the app stores and markets have an app that they ask you to install before start downloading apps. But it is quite clear when you download the app of the appstore and when you download the app that you want. Before submitting an app to legitimate appstores like Amazon and Google Play you go through an extensive check of your ID, they even cross-check the information you provide with IRS. In mobogenie they could do something like this, but they don’t seem to care as their location is in Asia and you will probably won’t bother to form an international law complaint.
Besides, my apps that I saw in mobogenie are distributed from Amazon and Play for free, the mobogenies probably think that I should not mind having in their site my free apps. They could ask first.

Open a file with default application in Android

Here is a technique to program an Android application to open files using the default application that it is associated with them. A part of this technique can be found in many other sites on the internet. The advantage of this technique is that you don’t need to specify the type of the files or the application that is associated with them.
At first you create a method and you input in it a file object pointing to the  desired file (let’s call it testfile), then it is only necessary to create an intent setting setAction(android.content.Intent.ACTION_VIEW) and intentview.setData(Uri.fromFile(testfile)) and then start an activity with this intent. When this method is executed the application associated with the testfile is executed and it opens testfile without closing your application.
The only problem with this technique is that there might be the case where there is no application associated with testfile. This can happen when there is no suitable application or the testfile has no extension. In this case there is an exception “android.content.ActivityNotFoundException” that must be handled. A convenient technique is to enclose the code in a try-catch structure so as to catch the exception and execute some other code that will direct the program to do something else, like opening the file in a text viewer or display some message.
Here is the code

File testfile = new File(//path of testfile);

 public void openfile(File testfile){
        try{
        Intent intent1=new Intent();
        intent1.setAction(android.content.Intent.ACTION_VIEW);
        intent1.setData(Uri.fromFile(testfile));
        startActivity(intent1);
        }
        catch(android.content.ActivityNotFoundException exception){

            //Do something else
+
        }
}

If Android was like an ordinary Linux distribution.

When Android was initially developed, it was design to work in devices with little processing capabilities; not much memory, slow processors, very low power consumption. So, the developing team of android took Linux, removed all the not so necessary features and Android became light and not very demanding; more like an embedded system.
Nowadays, Android enabled devices are equipped with a lot of memory big screens and multicore processors which make them powerful enough to carry complicated and demanding tasks. Still, the philosophy and architecture of android hasn’t changed much. Although I like Android very much, I can’t stop wondering how would it be if android was like an ordinary Linux distribution?

If Android could handle multiple user accounts like Linux 

 

While Linux is a real multiuser system, Android is mainly designed to handle Google accounts rather multiple user accounts. If Android was a multiuser OS like Linux each user would have his own desktop, home directory and settings. Each user would be able to do anything in his home directory like running a script or change permissions in a file, while the rest of the system would be protected. Currently, if you want to do these things you have to Root your device exposing the whole system. Also, each user could have installed his own private applications. To put it in a simple way, when children are coming to my house I could just log in to my tablet as a guest user and give it to them to play without worrying that they will mess up my e-mail application.

Android could have a fully featured console

There are many terminal emulators you may install in android. But if you do so, you find out that most of Unix commands do not work as they are either not installed or they require administrator user rights. As there is no home directory for you this situation affects the whole system; there is no directory in which you can do whatever you want. If you are an advanced user and you want to carry out more advanced procedures you have to install Busy Box a collection of Unix applications compiled for Android but you still need administrators rights; administrator accounts are not accessible. So you buy a high-tech device and you have to hack it so as to get the most of it. How sensible can this be?

Network transparency and remote system administration

With Linux things are simple. Using the console of your computer you can log in to some distant system and operate it like if it is right next to you. This feature is quite useful when you want to administrate some distant system without physical access to its hardware.  This is a very advance feature of Unix. You don’t just get the control of the desktop of the distant system, as it happens with most distant administration applications of Windows. In Unix you actually log in to the system itself.
If such a feature was easily accessible in Android, then we could talk about the support of distant system administration on the move. You could be in an island in the middle of the ocean and check the network traffic of you server in New York. Currently, if you care to do this it is necessary to install an application in your server and a corresponding one in your tablet and then set up a connection and you will probably end up being in control only of the desktop of your server ...... boring.
It is my belief that Android should gradually adopt the traditional features of Linux that are now hidden or ignored. Such an approach would benefit advanced users a lot.

Android application submission; Amazon App Store vs Google Play.

I recently submitted applications both in Amazon App Store and Google Play and I think it is interesting to discuss the main differences of these two services. As far as it concerns android applications both of them want to work as electronic stores, so one might think that they should have similar functionality. The truth is that they have different approaches on the way they treat developers and on the demands they have from them. Let’s look at their differences in sections.

Registration

In Amazon you need to perform a full registration right from the beginning. The information you provide are cross-validated with IRS and your registration looks and actually is very formal. It is also for free. In case you submit applications for which you expect to get some royalties you only have to add a bank account.
In Google Play you have to create a Google account, then pay 25$ using a valid credit card; prepaid cards work fine, I tried a debit card and it didn’t work. If the apps you submit are for free your registration information are not cross-validated and I think there is a relaxation in the control of the accuracy of the information you enter. The only cross-validated information you have entered up to this stage is your credit card. In case you expect to make money from you apps you need to get registered as a trader. At this point your registration is cross-validated and you need to be accurate in what you declare. Also you need a bank account.

Target devices and promotion

Google Play wants to please everybody. So while submitting an app, you are welcomed to provide screenshots and graphics suitable for all kinds of devices; small phones; larger phones or tablets; 10’ tablets. At least 3 screenshots are required. You are welcomed to put a YouTube video but you need to apply promotional images of different resolutions for users that will not watch your video. Besides any low resolution image, you are also required to apply a 512 x 512 pixel icon of your app.
After acceptance of your app you may promote it any way you wish. You can pay for advertisements or do your own promotional campaign.
Amazon produces its own Android devices. So, you are highly motivated to submit apps compatible with them and also use their SDK. Amazon devices are the Kindle devices (readers, fire etc) and the new Fire Phone and Fire TV. Also, you are motivated to support the latest high-end devices with HD screens etc. Your app may be accepted even if you do not fully support these devices, but this is not a wise thing to do. Until February 15th 2015 an app that supported Kindle and HD was promoted through Amazon advertisement system getting as bonus many thousands of appearances in devices of potential clients. This promotional benefit was called Developers Select program; unfortunately it has stopped. This required that you will also provide screenshots of 1200 x 800 pixels or higher. Extra promotional motivations was given for support of special features of Fire Phone and Fire TV.
For most Kindle devices your apps needs to maintain compatibility with some older Android versions and have support for HD screens. For Fire Phone you need to integrate special widgets designed for the phone using its SDK. For Fire TV the support of its special controls is required.
Another difference between the two services is that in Amazon you can set a period during which your app will be available with a discount, even for free and after this period it will return to its normal price. In Google this not possible, you have to manually modify the pricing of your app and once you select to give it away for free this cannot be changed in the future.

Submission procedure

Amazon does not support Google Maps later than version 1.2 at least up to now.
In Amazon you can test your application before submitting it and even distribute it to some reviewers to get some feedback and pre-submission reviews. As it is announced 75% of the submitted applications pass the tests.
Google Play does not allow the packages in your app to have a prefix name “com.example” although this is a default choice in Eclipse. This is something you find out a few seconds after you submit your app; no one warns you earlier. In Google you make a full submission and then your app is tested.
Another issue with Google is that it requires the title of your app to be at most 30 characters long. This does not happen with Amazon. So, if you publish in Amazon an app with a title longer than 30 characters and then you want to publish it in Google Play you will have to shorten its title.

In-app purchase

A key difference between the two services is that when you purchase an in-app item in Amazon your purchase is not time restricted, while Google Play allows the developer to sell in-app items and services for limited period of time, such as annual subscriptions for something etc.

In-app advertising

For the advertisements of Google that you display in you app, you will be paid according to the number of times that the users have clicked on them. The same thing holds for advertisers, they get charged for the number of clicks on their advertisements.
In Amazon things are quite the opposite. Advertisers pay and developers are getting paid for the number of “impressions” of each advertisement. One “impression” stands for a single appearance of an advertisement in a device of some user through an app. Unfortunately Amazon ad network currently covers  only U.S.A., U.K., Germany, France, Spain and Italy.
Comparing the two pricing policies I have to say that a click of a Google app costs more than an impression in Amazon; but this is not a good criterion. Which policy is more profitable is case-dependent. If your app is used quite frequently by your users, then the policy of Amazon sounds better; you may get more impressions than clicks. In case your app is used once a week of some short operation then the policy of Google may be more promising as you will not get many impressions.

Licensing - Protection from unauthorized copy

Both services provide mechanisms for protection of unauthorized copying of your app. And in both services the use of these mechanisms is optional. It seems to me than when you release a free app you probably don’t care about unauthorized copying but this is your choice.
In Amazon during the submission you may choose to use the DRM (Digital Rights Management) of Amazon. In this case Amazon puts its own signature in the apk file of your app. When a user installs an apk signed with DRM, the application of Amazon checks if the specific apk is authorized to be installed in the particular device. If so, the apk is installed and work without any further check or disturbance. If the apk has been illegally purchased the app is not installed.
In Google the licensing service is quite different. As a developer you have to add extra code in your application so it may use Google Play Licensing which is a network-based service. Google Play Licensing determines during the installation of an app if a given user is licensed to use the app. The code that the developer has to add in the app is the License Verification Library (LVL) provided by Google.
There is one thing for sure. If you choose to submit an app in both services and you want to prevent unauthorised copying of your app you may not submit the same apk in both services and the apk’s will end up having different signatures.

I can’t say that I prefer one of the two app stores more than the other. Using both of them is more interesting as a user and more promising as a developer.