The Lessons from Android Things

Android Things was:

• Announced in December 2016
• Released as a 1.0 in May 2018
• Killed off (to a large extent) in February 2019

In principle, “OEM partners” can still use Android Things… for whoever Google decides it wants to have as a partner.

Given Google’s propensity for killing off stuff, this development is not a major shock. However, it is undoubtedly a death knell for many projects in the pipeline that relied upon Android Things, particularly projects from smaller organizations.

So, what can we learn from this? Here are two key lessons:

Lesson #1: The Future Is Murky

You never know when the environment around you is going to change. What the world is like today (“Android Things is awesome! Everyone should use it!”) may not be what the world is like tomorrow (“Android Things is OK, if you’re big, you’re working on particular products, and Google likes you!”).

For example, while Fuchsia might be a thing someday, even after it is released, there is the potential that Google might pull the plug on it. Conversely, if Fuchsia is released, it’s entirely possible that Google quickly pulls the plug on Android and starts scaling back its support and services. We just have no way to know what may transpire.

Lesson #2: Build In Business Redundancy

The “thing” that worried me most about the Android Things plan is how dependent firms would become on Google. If Google is the one that is distributing firmware updates to Things, what happens when Google decides that it does not want to do that anymore?

I guess some people are going to find out.

The more you rely on particular suppliers or service providers, the greater your risk. Should somebody that you depend upon become undependable, you and your customers may suffer.

In the case of IoT, if you use a managed firmware update service like Google offered, what is your plan if that service goes away? How will you distribute firmware updates without them? Is it even possible for you to distribute firmware updates, or do they hold signing keys or other credentials that block you or anyone else from updating the firmware?

For Android app developers:

• Have more than one app distribution channel. Do not assume that your users will always be able to get your app through one particular channel, in case that channel stops liking you. And while you may think that your app is immune to such problems… so did the developers of many apps that have subsequently been banned.

• A side effect of the above: always sign the app yourself. You are what you sign. If you rely on Google to sign the app (as is the case with App Bundles), will you be able to sign it yourself if Google elects to stop distribution of your app? If not, even if you have another distribution channel, will existing users be able to get updates through that channel?

• Have more than one means of accepting payments. This is one of the big risks with in-app purchases: if your channel stops distributing your app, you also lose your revenue. Ideally, organize your app and business such that there are legitimate reasons to purchase outside of the app (e.g., to be able to use your Web app), so you can support both channel-based payments and payments via other payment processors.

Note that while I am using Google as an example here, they are far from the only source of these type of disasters. Apple, PayPal, Facebook, and countless other companies view you as a source of revenue at most. Don’t depend upon them. Use them, but make sure that you have alternatives, either live (e.g., supporting multiple payment processors) or at least tested (e.g., self-distribution of the app).

In the 1960’s, it was “don’t trust anybody over 30”. In the 21 Century, perhaps it is “don’t trust any firm with over $1 billion valuation”.