Blog

A new monetization strategy for Android Apps?

Enno September 7, 2011 BrickJoke 6 Comments

Traditionally, there have been two ways to make money from apps on Android. You can either try selling the app, or you can put advertisements in. More recently, in-app payments have arrived, and most of the top-grossing apps get much of their money here. Unfortunately, all of these have their disadvantages.

So, when trying to decide how we could get money from our apps, we realized that there was another way. Following the example of distributed computing projects like SETI@Home, we can take advantage of the available processing power of cell phones. Most of the time, this power is just wasted waiting for a call to come in or for someone to push a button.

Of course, it’s not very easy to make money just by having these phones available. Or is it? In a wonderful coincidence, we had just recently become aware of the Bitcoin project, which is an entirely digital currency.  In this project, it’s possible to earn bitcoins by performing certain calculations. The bitcoins can then be exchanged for goods or other currency.

Putting these two together, it seemed like a good idea to use these phones for Bitcoin mining. Of course, we didn’t want to inconvenience users by draining their batteries or slowing their phones. To keep our calculations as unobtrusive as possible, we would only run the calculation when all of these conditions were met:

• The phone is plugged in to a charger, and the battery is fully charged. This way, we don’t drain the battery, or slow down charging.
• The screen is either off, or showing the lock screen. This way the phone doesn’t get any slower when you’re using it.
• The phone’s temperature is below 40 degrees C. While testing we noticed that some phones get noticeably hot when heavily used, and we didn’t want to risk damaging the phone or reducing its lifespan (the battery, in particular, degrades quite fast when hot).

Despite all these restrictions, we still manages to get several hours of processing time per day, per phone.

Technical details

The next problem is how to get the information needed to do the calculation.  Producing bitcoins involves finding a valid ‘transaction block’, and to find such a block, you need to know the previous block. A new block is found every 20 minutes, on average, so a Bitcoin miner needs to have up-to-date information about recently found blocks.

There are basically two solutions to this problem: First, we could integrate each phone in the global Bitcoin network, and be notified almost immediately when a new block is found. We decided against this because it is quite complicated, and we wanted a quick solution to see if this would even work.

The second option is to join a ‘Bitcoin pool’. This is a group of people who have agreed to work together to mine Bitcoins. There are several reasons to join a pool, but the biggest one for us was that pools have a central server which notifies everyone of new blocks without much hassle.

The particular pool we use, Deepbit, supports two ways of distributing blocks. The normally preferred method is long polling, which distributes new blocks as soon as possible. The other method is just polling, in which client ask for a new block every minute or so. Because of limits imposed by Deepbit, we had to choose the seconds method.

So, all that remained now was to do the actual calculations. This didn’t take very long (the biggest problem was actually with the representation of the data, which is rather poorly documented by the Bitcoin project).  We wrote two programs to mine Bitcoins, one for processors that support NEON extensions, and one for processors that don’t. Both of these were written in C, to get as much speed out of each phone as we could. At this point, we were basically ready to release a test version of what we called the BitMiner service. But there was one more thing we wanted to try.

GPU Mining

One approach that seemed very promising at first was to use the graphics chip as well. GPUs are orders of magnitude faster than CPUs on the desktop, and we had hoped the same would be true for phones.

Two things I learned from the experience of trying to write a Bitcoin miner for the GPU. First, debugging shaders is absolutely horrible. Without even the ability to log messages, the only way I could think of to get information out was to set the color of the pixel I was working on.

The other thing is the OpenGL ES shaders are utterly unsuited for the type of calculation that Bitcoin mining needs. There is no support for integers bigger than 16 bits (in fact, no support for integers at all, although it will happily give you floating point numbers that pretend to be integers in a certain range), and no ability to do bitwise operators.  Emulating these is not that difficult, although I never expected to write a one-bit-at-a-time XOR function.

Having finally written something that ran on the GPU, the time came to do a benchmark. In hindsight, it should have been no surprise that performance was abysmal (the one-bit-at-a-time XOR should have been a clue). We quickly abandoned this approach.

Results

The culmination of all this effort was a working Bitcoin mining service, which we included in the BrickJoke app. After fixing a few bugs, we eventually got a fairly steady income from it. With 600 installed applications, we earned a grand total of 2 percent of a eurocent after three weeks.

So, mining Bitcoins is a viable monetization strategy for Android apps, provided your install base is in the millions and you don’t mind earning only a few percent of what you could have gotten from a more traditional strategy.