Tag Archives: android

Flappy Bird: A New Model for Software Innovation?

Okay, I know that the title may already have some people scoffing, but bear with me for the moment. This is about more than just Flappy Bird.

Picture this with me, if you will: you have written an app. You have written an app, and its popularity has skyrocketed. The ad revenue has gone through the roof. Suddenly, you are accosted on all sides by people saying things about your app. You had no idea that this was going to happen: as far as you were concerned when you wrote it, it was just another idea you wanted to try out. There was nothing to distinguish it, for you, from any of the other ideas that you had had, none of which had ever made much money.

So, what to do? You are a lone developer. You don’t have a PR department, so you have no way of dealing with the media circus that is suddenly surrounding you. You don’t have a legal department or experience with lawyers, so you also have no way to deal with the legal issues that may be raised – for instance, claims from users about health effects, claims from intellectual property holders about potential violations – not to mention the fact that you may find that you remain personally liable for these things, even after you incorporate or sell the app (which is something that may crop up when dealing with things like the Google Play Developer Agreement).

A naive solution

So what can you do? Well, the obvious things to do are either to build a new company around it, or to sell the app to a company that is already well-placed to handle this sort of concern. However, the fact that the app was released through Google Play might make this somewhat hard.

There are three main problems that I am aware of:

1. You can’t transfer the app to another Google account without also transferring the signing key (which the receiving entity requires in order to distribute software updates).

If you use the same signing key for other apps that you have written, you will probably be very reluctant to transfer it, because doing so will, in principle, give the recipient the ability to issue updates for your other apps, as well as make use of certain Android resources that are shared between your apps – such as custom identity providers (which may be unique to your particular “ecosystem” of apps) – which, in turn, may make it impossible for you to meet your legal obligations to your customers.

It will also, perhaps more importantly, mean that you no longer have control over the key’s security. This will be important to you if you want to continue supporting your old apps (which are also effectively “tied” to their original key), ensure your customers’ security, and release new apps of your own that are tied into the same identity ecosystem.

Releasing the new app under a separate package name does “solve” the problem – but only at the cost of automatically losing all of its existing customers, which may quite probably defeat the purpose.

2. You can’t transfer the Ad Units to another Google account – which the receiving entity needs in order to receive your Ad revenue.

It is true that once you have transferred the app, you can issue an immediate software update changing the Ad Units to ones owned by the receiving entity. However, in general, it is not compulsory for users to accept updates, and I have heard horror stories of app developers’ revenue streams falling off dramatically after they have been required (because of upgrades to Google’s platform) to switch their existing apps to new Ad Units – presumably because many users do not accept the update, and therefore continue to use a version of the app that uses the old Ad Unit.

One reason why users might switch off automatic updates is to save on bandwidth charges. Once a user has done this, each update is effectively “opt-in” and many users will simply not bother.

3. You can’t transfer your liability to another entity, under the Google Play Developer Agreement. (At least, without getting special approval from Google – and good luck with that.)

This is a particularly nasty one. Let us suppose that company “A” wants to buy your app. Company “A” is in the business of managing and supporting apps, and is willing and able to accept full legal responsibility for it from that point forward, as part of the purchase deal.

Now, you also give company “A” the app’s source code as part of the sale, and at some point it will release an update to Google Play. However, suppose that 50% of the existing (active) users choose not to update, and therefore carry on using the app in its prior state. These users received the app before the transfer, and therefore, full legal responsibility for their use of the app rests with you, according to the Google Play Developer Agreement. Moreover, this responsibility is non-transferable, and so it remains with you, even after the transfer of ownership. If someone decides that the app is infringing their IP (for example), they will not only be able to sue company “A” – they will also be able to sue you.

Now, I can see simple technological solutions to points 1 and 2 (requiring action by Google, unfortunately), and I can see that in principle it should be possible for Google to implement a legalistic solution to point 3.

Technological solutions

My solutions to points 1 and 2 are as follow (in reverse order):

2. The existing signed app (apk file) already functions as, effectively, a signed “request” asking the Android OS to use a particular Ad Unit. The cryptographic signature certifies that the request is from the app’s owner. This helps to keep the system secure, preventing a third party from forging a “request” and redirecting the ad revenue to their own account. A new signed request, changing the Ad Unit, is at present created by uploading a new signed apk file (i.e. an app update). The “request” is then honoured on a per-user basis, when (or if) they decide to accept the update.

However, there is no technological reason to require this particular protocol. A better protocol might be to allow the owner to sign a “request” consisting of only the unique package name of the app, the old and new Ad Units, and a special identifying code indicating the type of request being made (e.g. “ReplaceAdUnit”) (plus a timestamp). So the request might look something like this:

1400251570 ReplaceAdUnit com.mycompany.myapp 8f3b24fc 332bce29

After this has been signed using the normal signing key for com.mycompany.myapp, and then uploaded to Google, all requests from this particular app to the Google Ads API requesting Ad Unit “8f3b24fc” can instead be served using Unit “332bce29”, from the request timestamp (represented by 1400251570) onwards until any further such requests are made. Any further requests can change the Ad Unit again by referencing Unit 332bce29 – and requests for 8f3b24fc, as well as 332bce29, will be redirected to the new Unit (and this can be repeated indefinitely – the Ad Units will form a chain that can be followed iteratively, always picking the newest record and checking for monotonically increasing timestamps).

1. The solution to problem 1 should now be obvious. Another type of signed request can be created. Instead of replacing the Ad Unit, this time the request is to replace the signing key – perhaps call it ReplaceSigningKey. The request then consists of this operation identifier, plus the unique package identifier of the app, and the fingerprint of the new key (plus a timestamp). From that moment onwards, all updates to the app, as well as (naturally) all further signed requests, must be made with the new key – the old one will no longer work (this is important because the entity you are transferring it to may not want you to retain the ability to release signed versions of their app). No connection is established between the new and the old key – the new versions of the app will be within a new “domain” as far as Android is concerned, just as usually happens when a different signing key is used. Again, this helps with transfer-of-ownership scenarios.

This also, incidentally, helps ensure key security by allowing you to expire your old keys (in case they have been compromised).

Unfortunately, this change probably requires changes to the Android OS on each individual device. I am not sure how feasible this would be. It may be possible to implement it through an update to the Google Play app.


In the case of point 3, it is clear that Google is placing legal restrictions that are artificially restricting the rights of individuals and businesses through Google’s monopoly-position on the provision of this particular type of publishing contract. Google Play is currently one of the world’s largest markets for computer software, and individuals and businesses cannot simply decide not to publish through Google Play: it is a practical necessity for certain types of business activity in today’s changing world. Therefore, by failing to include provisions for reassignment of liability in their standard publishing contract, it could be argued that Google Play is here abusing its monopoly position.

What may not be so clear is that the same argument could be applied to points 1 and 2. In both cases, Google is failing to provide the necessary flexibility for its users to carry out their business activities with the freedom to isolate, buy, and sell, business units as appropriate, making their cloud data usage securely separate as and when it is found to be appropriate. It is therefore, effectively (whether intended or not), forcing its customers into a certain pattern of internal organization, as a condition of performing certain activities that are necessary to their normal functioning as businesses – which could also be seen as an abuse of its monopoly position.


Leave a comment

Filed under Law, Software industry

New open-source dictionary for FBReader on Android

I’ve just finished work on a new dictionary for FBReader on Android (FBReaderJ). The code is on my github account (a fork from geometer’s official version, which is available from the official website or the official github account). It doesn’t look like much at the moment, and frankly the code’s a little bit of a mess, but it reads the dictionary files! And it puts words on the screen! Seriously, what more could you ask for??!

Anyway, the main reason I wanted to do this was that as far as I could see there didn’t seem to be a suitable open-source Android dictionary app to go alongside FBReaderJ. At the moment the only option is to install a closed-source App, which FBReader uses as an external service. This meant that there was nothing to work on to make the customisations I wanted to make. So I thought I’d remedy the situation!

What customisations, you might ask? Well, it may sound silly, but one major thing was that I wanted to be able to move from one entry to another without having to press the screen twice. The existing support requires you to press the screen to make an entry disappear, before pressing it again to bring up another one. Small, but can have a high impact on usability, particularly for a language learner.

Of course, I’ve since realised that my efforts were probably largely unnecessary. I probably didn’t have to reimplement StarDict dictionary support for Java – that was already available as part of the (mostly extinct) babiloo project, it seems. Also, I possibly could have figured out how to use the Android APIs to do a textual query to some service provided by (closed-source) ColorDict or something (not sure about this; what I’m really thinking of is the Android Quick Search Box functionality, and as far as I can see [from this page], it brings up its own dialog on screen). Also it’s just occurred to me that I might have been able to get the ColorDict Activity to behave in a similar way by giving it some kind of rendering hints in the Intent or something. I don’t know.

On the other hand, there are other customisations that I want to make, but more on those another time… 🙂

Well anyway, here’s a free screenshot in case you don’t believe me. 🙂 As you can see, it’s not displaying the whole entry (but this should be comparatively simple to fix). The text is from WordNet, I believe.

Right, now I’m off to bed ’cause it’s one o’clock in the morning. Either that or to stay up all night coding on my next crazy idea. Not quite sure yet.

Leave a comment

Filed under EBooks

Turning ePub chapter end-notes into “popups”

Lately, as part of my efforts to learn French, I’ve been trying to read Rivarol’s French translation of Dante’s Inferno on my Android mobile phone. I’ve mostly been using Kindle, but I have also tried FBReader. I’m not sure what format Kindle uses, but with FBReader(J) I’ve been using the ePub version from gutenberg.org.

One problem I’ve been finding is that all of the end-notes are at the end of the chapter (as you might expect), and it is hard to flip back and forth between the end-note and its reference. To remedy this, I decided to find a way to make the end-notes appear as “popup” boxes over the main text. Unfortunately, this was not directly possible with the fairly limited ePub format (or, at least, not with FBReaderJ). A simple solution was to (1) put all of the end-notes at the end of the document, rather than the end of the chapter (so that you wouldn’t have to skip over them), (2) create hyperlinks allowing you to jump back and forth between each reference and its corresponding end-note, and (3) put a page break after each end-note entry so that you only see one at a time. To achieve (3), one way in FBReaderJ is to simply put a new level-2 heading at the start of each entry, which causes it to be put on a new page.

Luckily, the ePub format is very simple, consisting of just a few XML files contained in a ZIP archive, with the actual content being stored in XHTML format. My usual approach to this kind of problem would be to hack something up in Perl using regexps. However, this time, I decided to do something in Java, partly because I had some kind of idea that I might try to integrate it into FBReaderJ at some stage. This has probably led to it taking twice as long and ending up twice as complex, but on the other hand it has improved my knowledge of Java’s XML libraries.

Here is an example of the result, looking at a paragraph from Dante’s “l’Enfer” chapter 18 (the text is public-domain). Notice the blue link reading “[end-note 1]”. Before processing, this was simply “[1]” (and not a link). I added “end-note” to make it a bigger target.

And here is what you get if you click it:

…And there’s a link back to the reference’s location in the main text. As you can see, the link text I have added is in English. In retrospect, perhaps it should be in French :).

It took surprisingly long to write the code for this, considering how simple it seems now. But I did have to update the OPF descriptor file, and the toc file as well, and create tables of all the relevant ids to create the links, and then separate the end-notes out into a separate document so they could all go at the end without risking hitting some obscure ePub file size limitation, all while wrestling with the w3c DOM in Java… you get the picture :). I think my program should work with all of the rest of the ePubs in the same series (Rivarol’s French Dante – so far I’ve only tried it with l’Enfer [Inferno]), and it should be fairly easy to adapt it to work with slightly differently formatted documents.

I am continuing to work on trying to make FBReader a better platform for language learning. I have a funny feeling my next stop is going to be to do something with ColorDict…

Leave a comment

Filed under EBooks