Advice for Niche Android Hardware Manufacturers

Last week, I heard of i’mWatch, which appears to be an Android-powered wristwatch.

Of particular interest is this listed feature:

download apps from i’m store: each downloaded app offers new functions to your i’mWatch, making it more and more fun and capable of doing extraordinary things.

This is not the first niche product based on Android, where by “niche” I mean “not fitting the established phone, tablet, and TV market segments”. Of course, today’s niche is tomorrow’s “established market segment”, particularly if Google endorses it. But, for the moment, niche is niche.

Some of these niche products will be sealed appliances, akin to the dumbphones of yesteryear. The product will have such-and-so apps pre-installed, and that’s it, other than perhaps some OS updates pushed by the device manufacturer.

Others, like i’mWatch, will be explicitly open to developers, albeit mostly from their own markets, as niche products may not meet the requirements set forth in the Compatibility Definition Document to be authorized to distribute the Android Market.

Here is some advice for manufacturers of niche Android devices, with respect towards working with developers:

• Engage developers early and often. Your product will be underwhelming if you launch it, touting your own market, with an empty market. Developers will need time to get their apps tuned to the particulars of your device – in the case of i’mWatch, the screen size is likely to be smaller than any Android developer had ever planned for.

• Be sure to set up your firmware to advertise its capabilities properly to developers. In other words, make sure that <uses-feature>, <uses-configuration>, <supports-screens>, DisplayMetrics, and so on all work as a developer would expect.

• Make getting apps into your market as simple as possible. By “simple as possible”, I really mean “ten times simpler than your legal and Web site teams think is possible”. Your product is not only niche in terms of market segment but in terms of market penetration. Every “speed bump” you put in the road towards getting developer apps on your devices reduces the number of developers who will bother. 28 page obtuse “legal agreements” and awful options for describing their app on your market are two examples of such “speed bumps”.

• Publish an SDK add-on for your device. It should support an emulator image that matches your device. It should provide compile-time libraries for any extra capabilities you want developers to use unique to your device, akin to the library needed to use Google Maps. At the barest minimum, you need to document the emulator settings that developers should use with the stock emulator images to get something that resembles your device configuration.

• Thou shall not steal. Do not pirate the Android Market client. Do not pirate Android developer apps. License them appropriately from their respective authors. In other words, do unto others as you would have them do unto you.

• If there are specific popular Android apps that you want to have on your device, shower their developers with test devices and any other benefits you can come up with. Some of those developers may have policies against that sort of thing (e.g., government employees), but at least be prepared to offer it.

• Have some way for other developers who want to support you to be able to get their hands on hardware. At worst, get your device into a service like DeviceAnywhere. At best, run a loaner program or a developer discount program or something, so developers can actually have the hardware in hand. This will be particularly important for devices like the i’mWatch, where the form factor is substantially different than what developers are used to.

• Have some sort of developer forum where developers can contact you with device-specific questions or bug reports. This does not have to be a general Android developer support point – questions that do not pertain to your device probably should be steered to StackOverflow and kin. However, the only way you are going to find out about problems is if you let people talk to you.

Now, some niche hardware makers have read this list and think that none of it applies to them, because their devices are appliances and do not support third-party developers. In reality, just about any Android device can and will get hacked to run alternative firmware, ones that will allow third-party apps, whether the maker likes it or not. The reputation of the product will, in part, be set by how easily these devices can be repurposed (e.g., i’mWatch serving more as a LiveView-style secondary display to a main Android device). As a result, all device manufacturers need to plan on third-party development, whether it is officially endorsed or not.

The good news is that Android can be applied to anything from wristwatches to Jumbotrons and back again. (NOTE: I’m still waiting for the first Android-powered Jumbotron) Making such a device a success depends in part on making third-party developers for that device a success. Take care of the developers, and they will help take care of you and your customers.