Attack of the Clones – Android Market Plagiarism

Posted in Android by Dan on March 3rd, 2012

Appmonger vs. Crapmonger

I was rather surprised on Thursday to be shown a newly released free app on Android Market that looked suspiciously like one of my paid apps. To me and other observers it appeared that this app was simply a modified version of Appmonger being touted by someone who claimed to have paid somebody over four thousand dollars to write it for her so that she could give it away for nothing.

I provide more details about the whole situation over at the Rectangular Software blog. The episode has left me somewhat confused both as to the motivations of this individual and the extent to which she and/or her coder have ripped off my work. Clearly (screenshots to the right to judge for yourself) this app is more than just inspired by or competing with Appmonger but after running the app and digging into the .apk I am now uncertain how much code, if any, has been copied/reused. She may actually have paid somebody else a tidy sum to write the whole thing from scratch. That sounds even more insane to me than just cracking somebody else’s code and passing it off as your own. Why go to all the effort of building an entire app without putting your own stamp on it to avoid any accusations of plagiarism or copyright infringement?

The Android-To-PlayBook App Repackaging Experience

Posted in Android, Blackberry by Dan on February 11th, 2012

Having convinced myself that I’d quite like a new Blackberry PlayBook courtesy of RIM’s bribe-an-Android-developer program, I have just completed the process of repackaging a couple of Android apps and submitting them to Blackberry App World. This was my first experience of publishing on a Blackberry platform. Previously I had been scared off by horror stories of the pain involved.

The first step was to become a registered Blackberry App World Vendor. This involved e-mailing some documents to RIM to prove that my company actually exists (if you are selling apps as an individual you have to provide proof of your own identity). I submitted the documents on Friday and was approved by Tuesday, which is not too bad considering that they were probably processing a much larger volume of applications than usual due to the free PlayBook offer. It was not as straightforward as signing up for Android Market or the Amazon App Store but it was a lot quicker than the 3 weeks it took Apple to process my application for the iTunes App Store.

The process of acquiring a code-signing certificate involves submitting another form and waiting an hour or two for a pair of e-mails containing a RIM Development Key (RDK) and a PlayBook Debug Token (PBDT). It took me two attempts at this to get both as the first time only the RDK arrived. Once you have the necessary files you then have to use the tools provided to register with RIM and create a developer certificate. This degree of cryptographic hoop-jumping is beyond that required by Google or Amazon and more comparable to Apple’s Provisioning Profile rituals (except much slower due to the waiting around). The whole process is unnecessarily convoluted.

When you’re ready to convert your Android app you’ll want to install the PlayBook simulator so that you can test it. The simulator is provided as a VMWare machine image wrapped up in an installer that is only available as a .exe (for Windows) or .dmg (for OS X). If you develop on Windows this is fine, you can use the free VMWare Player. RIM doesn’t seem to encourage development on Linux but if you can extract the files from the installer you can run the simulator using the free VMWare Player for Linux. The situation on OS X is less satisfactory. There is no free VMWare Player so you’d have to buy VMWare Fusion (£39.99). I was unable to get VirtualBox to boot the image. The simulator also has a major limitation in that it is not possible to change the device orientation, which is less than ideal for testing.

Finally it’s time to convert your app. Firstly you need to make sure it doesn’t use any of the many Android features that are not currently supported by the Blackberry Android app player. There is a verifier tool that will check your .apk and warn you of any problems. You can then convert the .apk into a .bar file, which is a simple one-step process.

Load this .bar onto the simulator, launch your app and then feel the disappointment really kick-in. On the simulator (on my laptop at least, under both Windows and Linux) the experience is abysmal. The apps flicker very badly with artifacts from the previous activity frequently appearing on top of the current activity. On top of this, font rendering is atrocious. Getting useful screenshots for uploading to App World is just about impossible.

I tried multiple Android apps and I know others have experienced similar problems with their apps. I can only hope that it is specific to the simulator and is not a problem on the actual hardware. If not, it needs to be fixed in the final Blackberry Tablet OS 2.0 release otherwise there is absolutely no point in repackaging your Android apps since they will be unusable.

Ignoring the app’s performance on the simulator, the final step is to sign the .bar file and upload it to App World. Signing is straightforward. Submitting the app is not too much different to other app stores. Bizarrely App World restricts screenshots to a maximum of 640×640 pixels (the PlayBook’s screen is 1024×600 so you have to reduce the size). As with Android Market, you are required to upload a feature graphic, although in this case it needs to be a massive 1920×1186 pixels. If you are selling paid apps you don’t have the pricing freedom that Android Market provides. Instead you have to pick from one of the pre-defined price points, just as on iTunes.

I’d be more enthusiastic about Android apps on Blackberry devices if it weren’t for the simulator glitches. As it stands I’ll have to wait until I get my hands on the hardware to judge just how worthwhile it is for Android developers to deploy to non-Android platforms.

RIM’s PlayBook Push – Repackage An Android App, Get A Free Tablet

Posted in Android, Blackberry, Hardware by Dan on February 3rd, 2012

It’s fair to say that Blackberry maker RIM’s tablet offering, the 7-inch PlayBook, has not been a commercial success. Launched in the UK at a £399 price point last June, by October the 16GB model’s price had been slashed to £249 in the face of underwhelming demand and last week RIM cut the price again – this time to £169.

In the VAT-free US the asking price is even lower, just $199 – exactly the same as Amazon’s Android-powered Kindle Fire. The two devices are both 7-inch tablets with 1Ghz dual-core processors and 1024×600 displays but the PlayBook has twice the internal storage (16GB vs 8GB), twice the RAM (1GB vs 512MB) and both front (3Mp) and rear (5Mp) cameras (the Kindle Fire has neither).  If Amazon struggles to break-even on the Kindle Fire, preferring instead to make its money selling content, then the current selling price of the higher-spec PlayBook must represent a significant loss for RIM.

To counter the growing consensus that it couldn’t give the devices away, RIM has started doing just that. Specifically, the Canadian firm is targeting developers in a last-ditch effort to rescue its ailing tablet platform from the squeeze being applied by Apple’s iPad and the myriad Android pretenders. All attendees at Blackberry’s Devcon in Amsterdam next week will be rewarded with a shiny new PlayBook and yesterday the company announced that it would give a device to every Android developer that repackaged an existing Android app for distribution on Blackberry App World (the PlayBook is capable of running Android apps non-natively). Today that offer was extended to include any developer publishing any kind of app (native, Android or Adobe AIR) on App World before the 13th February.

This industrial scale bribing of developers represents a concerted push to revitalise the PlayBook platform with the upcoming release of version 2.0 of the device’s QNX-based operating system. Increasing the number of tablet apps available on Blackberry App World is a core part of this strategy. For Android developers it’s an opportunity to get hold of what is by most accounts a decent bit of hardware for the minimal effort of repackaging an existing app.

Accessing Local Name-Based Virtual Hosts From the Android Emulator

Posted in Android by Dan on January 12th, 2012

To test mobile versions of websites, it is useful to be able to connect to a web server on your local machine from a web browser on an Android emulator without having to expose the web server to the Internet.  You can’t use the normal loop-back IP address of because that refers to the emulated Android device itself.  Instead you have to use to connect to the host machine.

That’s fine if your local web server is serving a single site, but if you are using name-based virtual hosting to serve different sites depending on the host name of the request (with aliases for localhost defined in your machine’s hosts file), then you need to be making requests from the browser using the correct host name, not the IP address.

The Android emulator does not use the host machine’s hosts file for name resolution so attempting to access http://myvirtualhost in the emulator’s browser will not work.  This is because the emulated Android device has its own hosts file, so you have to update this to map the virtual host names to the local machine.

The first step is to start the AVD with an increased partition size otherwise you may get an out of memory error when you try to save the modified hosts file:

  emulator -avd MyAVD -partition-size 128

You then have to remount the system partition so that it is writeable:

  adb remount

Then copy the hosts file from the emulated device to the host machine:

  adb pull /etc/hosts

Edit the hosts file so that it includes mappings for all relevant virtual host names:        localhost         myvirtualhost1 myvirtualhost2

Then copy the updated file back to the emulated device:

  adb push hosts /etc/hosts

You should then be able to visit http://myvirtualhost1 in the emulator’s browser and see the correct site.


Posted in Books, iOS by Dan on November 9th, 2011

AppillionairesAppillionaires is a new book by Chris Stevens about the mobile apps gold rush. I received my copy from Amazon yesterday and within a day I’d finished it, which, if nothing else, is testament to its readability.

Stevens’ credibility on this topic comes from his first-hand experience as a successful publisher of interactive books for the iPad. Early in the book he draws on this experience to articulate the seductive appeal of a new world of possibilities for independent software developers.

Overnight we were a global sensation – newspapers and blogs all over the world were hailing us as the future of publishing. Watching the money roll in and the download statistics rise became a minor obsession. There’s something wildly captivating about viewing your successes through the microscope of modern analytic software. Second by second, hour by hour. It provides the kind of statistic fetishism where viewing download graphs by geographical region or time of day becomes an opportunity to self-indulgently wallow in your accomplishment.

Appillionaires focuses exclusively on the iTunes App Store and the iOS platform. The Android Market is mentioned only in passing and other stores not at all. This doesn’t detract from the book though as, in terms of paid app sales, the iTunes App Store is still a long way ahead of the competition and it’s not an unreasonable assumption that successful strategies there will translate to other similar platforms.

The first third of the book reviews how we got to where we are today. The Apple worship is kept to a minimum and the company’s missteps in the mobile phone market are covered along with its successes. In particular, and in contrast to recent revisionist histories, Stevens doesn’t gloss over the failure of the first iTunes phone, the Motorola Rokr. He also reminds us that third-party apps were not part of the original iPhone offering. Steve Jobs was apparently reluctant to open up the platform to outside developers and at first it was only through the reverse engineering efforts of the jailbreak community that programmers were able to target the device.

Following the history lesson, the meat of the book is the five case studies of independent developers who have earned serious amounts of money from the App Store. As you work your way through these chapters it becomes clear that the book isn’t really about mobile apps, it’s about iPhone games. This is my one major criticism of Appillionaires. Games are a huge part of the mobile app revolution but they are arguably the least interesting part. The book gives honourable mentions to a couple of novelty entertainment apps (iBeer and Pull My Finger) but there is no space devoted to productivity apps, or location-aware apps, or any of the tens of thousands of actually useful apps that are making things just a little bit more convenient for millions of people every day. If just one of the gaming case studies had been dropped in favour of something from some other part of the App Store it would have presented a more complete picture.

There are several points that recur in most or all of the gaming case studies:

  • Developers of successful apps have usually released several largely unsuccessful apps before they hit on the winning formula.
  • Successful apps rarely become successful straight away. Sometimes they go through several versions, refining the formula until it starts to gain traction with app buyers.
  • Successful developers pay attention to small details and don’t settle for “good enough”.
  • Successful iPhone games use control systems that are well adapted to the platform, with intuitive touch gestures.

The final section of the book is devoted to business considerations. Stevens discusses how independent game developers are competing with, and being acquired by, the likes of EA, how the vast majority of developers are losing money on app development, and the threat of patent trolls such as Lodsys. This section aims to disabuse the reader of the notion that the Appillionaire outcome is common or even likely. Throughout the book it is made clear that luck plays a large part in which apps become successful. Also, through the choice of examples from the frontier days of the iPhone platform, Stevens gives an impression that, aside from talent and hard work, success was also partly due to being in the right place at the right time and that that time may already have passed.

This is a book that is grounded in reality. The success stories are enticing but the app developer path is frequently portrayed as a form of gambling with many more losers than winners. The gambling analogy is apt. In most forms of gambling if you look beyond the players you’ll find that the real winner is the house. The genius of Apple’s ecosystem is that developers have been convinced to play cards in a poker room with a 30% rake.

Fixing Disappearing Big Text on Honeycomb Devices

Posted in Android by Dan on October 30th, 2011

I haven’t seen this problem described anywhere else, let alone solved, so this post might prove useful to some desperate future Google searcher.

A couple of weeks ago I updated Rectangular Video Poker to support Honeycomb devices. In doing so I encountered a bizarre bug. The letter ‘J’ refused to display in one particular TextView. Neither the upper case or lower case variant would show, just a gap where the letter should appear. Every other letter in the alphabet displayed correctly. The problem occurred on the 10.1″ Galaxy Tab but not on the Honeycomb emulator or the two HTC phones that I tried.

The problematic TextView had a large font size (86dp) set for xlarge screens because it is used as a banner that displays the win/lose message at the end of a hand. Eventually I discovered that if I dropped the font size to 79dp the letter ‘J’ would reappear. In the absence of any explanation for this odd behaviour, making the text slightly smaller seemed to be a reasonable workaround. Why was ‘J’ the only letter affected? My best guess is because, in the default Droid Sans font, it is taller than all of the other letters. Unusually, the upper case ‘J’ descends below the baseline. The lower case variant is also taller than all other letters.

With an adequate workaround in place I ignored the issue until the other day when I encountered the same problem porting a different app to Honeycomb. This app uses a large TextView to display a number. The font size is even bigger (a scarcely sensible 142dp) and consequently none of the digits displayed. Again, the problem only manifested itself on the Galaxy Tab.

In this case reducing the font size wasn’t really an option (if anything I want to make it bigger to occupy more of the Tab’s very large screen). I did however establish that I would have to lower the size to 101dp to make the text reappear.

I couldn’t find any references to this issue anywhere online (maybe other developers aren’t as fond of massive text as I am). Eventually, due to lack of better ideas, I speculatively disabled hardware acceleration for the activity in question. Surprisingly this solved the problem. I had been following the advice given at the Android Developer Lab to turn on hardware acceleration unless you have a good reason not to, but I hadn’t realised it was the source of my problem because I hadn’t first tested the app without acceleration.

This is the second scenario I’ve discovered in which I have needed to disable hardware acceleration for an activity. It’s also necessary when you have a WebView with a transparent background.

Droidcon UK Day 2

Posted in Android, JavaScript by Dan on October 7th, 2011

Another day, another early train to London. Following yesterday’s Barcamp, the second and final day of Droidcon UK was for the scheduled presentations. Mark Murphy (a.k.a. @commonsguy/the StackOverflow Android guru) delivered a well received opening keynote (video here) containing several predictions of where the Android ecosystem is heading over the next 3 years.

The first of the inevitable sponsors’ keynotes saw Cisco pitch its enterprise Android tablet, the Cius. It’s a chunky 7-inch device (I’m sure they’d say “rugged”) and it only runs Android 2.2, but it represents a different approach to tablets compared to other Android device manufacturers. The main selling point is that it’s part of a fully integrated enterprise communications platform (VOIP, video-conferencing, etc.) that includes a desk phone docking station for the tablet. Later, in the afternoon, HTC touted its Android APIs for exploiting features specific to HTC tablets, such as the pen input on the HTC Flyer.

The rest of the day provided the opportunity to pick and choose from four streams of presentations. Erik Hellman from Sony Ericsson spoke about how to use hidden APIs in Android. These are features that are publicly available at compile time but explicitly excluded from Google’s documentation (via a Javadoc @hide annotation in the source). The examples were how to write code to access a device’s SMS message store and how to programatically toggle WiFi tethering.

Emlyn Howell from Accenture provided an interesting diversion with his discussion of the challenges of building in-car entertainment systems using Android. The thought of roads full of people playing with touchscreens rather than looking at the road is enough to make me never want to drive again, but apparently this danger is avoided by providing reliable voice control functionality.

One of the things you hope to get from events such as Droidcon is valuable insights that you can go away and apply to your own work. Truthfully, I didn’t really get so much of that from today’s presentations compared to yesterday or the ADL on Monday. However, there was one presentation towards the end of the day that I did find particularly interesting and intend to explore in more detail. James Hugman presented Kirin, a new JavaScript framework for developing cross-platform mobile apps with truly native user interfaces. The UIs are developed using the platform’s standard tools and then bound to the application logic written in JavaScript. This avoids the UI compromises of PhoneGap and Titanium Appcelerator while eliminating the duplication of logic that occurs with a strategy of 100% native apps for each platform.

Droidcon UK Barcamp Round-Up

Posted in Android by Dan on October 6th, 2011

Following on from the Android Developer Lab on Monday, I was in London again today for Day 1 of Droidcon UK. The first day of this two-day event is a Barcamp followed by a Democamp in the evening. This is a round-up of what I experienced in the Barcamp sessions (I didn’t hang around for Democamp, opting instead for an earlier train back to darkest Kent).

I hadn’t attended a Barcamp previously so I wasn’t entirely sure what to expect. In the end there was nothing particularly novel about the format, at least in the sessions I attended. After the initial pitching it was just a series of speakers delivering pre-prepared presentations like at any other conference.

10:20 AM – Terence Eden (InMobi)

I’m interested in finding out how to make money more effectively from ad-supported apps (my limited efforts with AdMob have not exactly been lucrative), and in the pre-presentation pitching session Terence was the only person to offer a monetary incentive to attend his talk (in the form of free InMobi advertising credit). Terence made two key points. Firstly, developers really should make sure that their apps are internationalised. Free apps can generate lots of ad revenue in countries like Japan and Indonesia if they are available in the local language. Secondly, app revenue is recurring. For apps that have a long lifetime, monetising using ads can be better than charging for the app in the long term.

11:00 AM – Ashay Padwal (Vserv)

Another mobile advertising talk. Vserv offers a system whereby ads are tacked onto the beginning and/or end of an app rather than intrusively within the main flow of the app. The technique used to implement this does not require any coding, it’s a modification made directly to the APK file. Vserv also provides mediation services to simplify dealing with multiple ad networks (this is presumably similar to AdWhirl).

11:40 AM – Cyril Mottier (GreenDroid)

I met Cyril and spoke to him briefly at the start of the day. He is the author of the GreenDroid library. I’d been aware of GreenDroid for a while but not had a chance to take a proper look at it. GreenDroid provides an ActionBar implementation for non-Honeycomb devices, a view pager, an asynchronous ImageView and other components for building compelling Android UIs. Cyril’s talk also covered techniques for ensuring that your Android GUI is responsive (e.g. using Handlers/AsyncTasks/IntentServices to perform background processing as appropriate).

12:20 PM – Chetan Padia (TouchType)

Chetan spoke about how the developers at TouchType (makers of SwiftKey) solved the problem of building multiple variants of their software from a single codebase. I was interested to learn about their approach as I have made my own attempts at doing something similar. The TouchType team’s approach is more sophisticated than mine and uses a combination of Ant and Python to manipulate their codebase. Part of this involves Java code generation. Chetan mentioned that TouchType is considering open-sourcing its build tool.

2:00 PM – Joe Moore (Pivotal Labs)

Joe spoke about Cloud To Device Messaging (C2DM). This is something I hadn’t done any reading about previously but I was interested to find out about (just how does the GMail app on my phone notify me of e-mails so promptly?). C2DM’s push messages are in most cases a superior option to polling, assuming that you control the server as well as the Android app (requires Froyo or later).

2:40 PM – Nicolas Klein (DataDroid)

Nicolas is another developer I had a chance to speak to early in the day. He told me about DataDroid and then said he wasn’t going to be giving a talk on it. He did give a talk on it. DataDroid provides a framework for managing data locally on the device and for performing REST web service requests to retrieve remote data.

3:20 PM – Martin ??? & Friedger Müffke

Martin and Friedger spoke about NFC. I don’t have a specific interest in NFC but the other talks at the same time didn’t appeal so I thought I’d listen to this. There was the usual mention of mobile payments and train ticketing, a brief demo of reading an NFC tag using an Android Device and some discussion of the other possibilities for NFC.

4:10 PM – Suzanne Nguyen (Immersion)

Again, I wasn’t especially concerned about haptics at the start of the day but this seemed more interesting than the other talks at the same time and, more importantly, I didn’t have to move from my seat after the previous talk. Suzanne spoke about how, using Immersion’s SDK, you can do more with haptic feedback than just basic buzzes. This is best demonstrated by Immersion’s free app that generates these various stimuli.

4:50 PM – Jouko Kaasila (Bitbar)

Jouko provided an overview of the tools available for testing Android apps. These included the Android SDK’s Monkey and monkeyrunner, Robotium (which is apparently like Selenium but for testing Android apps), Roboelectric (simplifies unit testing of Android apps by allowing code that uses the Android APIs to be run inside the standard JVM), and Bitbar’s own Testdroid.

What I Learned at the London Android Developer Lab

Posted in Android by Dan on October 3rd, 2011

This morning I took a brutally early train to London in order to arrive in time for Google’s Android Developer Lab at 8:30 AM. Developing Honeycomb applications for tablet devices was the primary focus of this gathering (around 30-40 Android developers attended) and Google’s affable developer advocates Nick Butcher and Richard Hyndman were our hosts.


Honeycomb has been on my radar since it was launched back in February but until today I hadn’t got much further than reading the overviews of what it means for developers (e.g. fragments and the action bar) and briefly playing with the painfully slow emulator.

One reason for my lack of Honeycomb activity is that the usage figures are still very low compared to non-Honeycomb devices (Honeycomb runs on just 1.4% of Android devices according to Google’s most recent figures). Today these devices are all tablets of one type or another but Nick cautioned against developing apps with the mindset that Honeycomb = tablets. The Honeycomb APIs are coming to phones with Ice Cream Sandwich (the next major Android version). ICS is apparently informally known as “Honeyphone” within Google, reflecting its focus on reunifying the two streams of Android by bringing Honeycomb’s innovations to phones.

Of course, some of Honeycomb’s features, such as fragments, are already available on devices running Android 1.6 or later via the Android Compatibility Library. Following on from this, another of Nick’s key points was that, whether you are targeting phones, tablets or both, if you are developing Android apps today and you are not using fragments then you are doing it wrong. Fragments are central to Honeycomb, fragments will be central to Ice Cream Sandwich, and fragments are already available (through the compatibility library) for all Android versions back as far 1.6 (Donut).

Android Market

The topics of the day were not all Honeycomb-specific. Richard provided a lot of useful and interesting information about the Android Market. One of the facts that stood out for me was that 7 of the top 10 highest grossing apps on the Market are not even paid-for apps, they are free apps that incorporate in-app billing. If you haven’t considered the in-app billing model for monetising your apps, you could be missing out.

As part of the Market discussions there was a lady in attendance (whose name escapes me, sorry) from the team responsible for the Android Market publisher console. She was collecting feedback to help guide future improvements. There were a lot of good suggestions made.

Richard also gave us the latest figures for Android device activations. There have now been over 150 million total Android device activations and this is increasing at the astonishing rate of 550k per day.

Porting Apps to Honeycomb

There are two very straightforward things to do first when updating an existing app to run on Honeycomb-powered devices. Both involve minor changes to AndroidManifest.xml. Firstly you should set android:targetSdkVersion to 11 or higher. This declares that your application is Honeycomb-aware and will result in it being given the Honeycomb default holographic theme.

The second thing to do is to turn on hardware-accelerated graphics. You need to test your app after enabling acceleration as there are some scenarios that might be problematic, such as custom drawing code, but for the vast majority of apps it is a free performance boost.

As for the frustrations of the very slow Honeycomb emulator, changes are afoot that will address that. In the meantime, Samsung furnished those developers fortunate enough to be present at the Android Developer Lab with a very agreeable alternative to using the emulator.

Kindle Fire Reignites Amazon’s Android Offering

Posted in Android, Hardware by Dan on September 28th, 2011

As expected, Amazon today launched the Kindle Fire, its own Android-powered 7-inch tablet (available to pre-order ahead of a November 15th release). At just $199 the device is even more aggressively priced than the $250 mooted by TechCrunch a few weeks ago. It’s clear that Amazon’s strategy is not to make lots of money selling the hardware but to use it to sell more e-books, MP3s, apps, films and other digital content. It’s this that makes it significant for Android developers – if things play out how Amazon intends, we should see a big increase in sales on the Amazon Appstore.

It’s striking how Amazon has completely down-played the Android underpinnings of its new machine. The word “Android” appears only once on the product page and only then as part of the name “Amazon Appstore for Android”. The Kindle Fire doesn’t look much like an Android device either. This is not a Google-endorsed, Honeycomb-powered tablet. In fact, according to TechCrunch, it runs a fork of Froyo (Android 2.2). Inevitably this adds to Android fragmentation concerns. It remains to be seen whether Amazon will release an emulator image to enable developers to test for this environment.

For now the Kindle Fire is disappointingly but unsurprisingly a US-only proposition. A wider launch of the Amazon Appstore could be imminent and it seems reasonable to expect that the Kindle Fire might follow sometime in 2012.

« Older Posts