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���.