How to build Android consumer electronics, part two

Android is an awesome OS to build custom consumer experiences on dedicated hardware. The rich, consistent, and well understood UI combined with tens of millions of developers is very stark compared to Linux. Yet the Android OS is weighted towards the massive smartphone market, leaving gaps for CE-specific experiences. In the first post in our series, I introduced some of the key business and engineering considerations that go into building a CE Android device. Now we’ll get into the tough stuff — the kind of stuff we can help you with.

This post is part of a series:

• How to build Android consumer electronics, part one
• How to build Android consumer electronics, part two
• How to build Android consumer electronics, part three

Esper is your foundation for great Android consumer electronics

Esper provides the table stakes — fine grained device configuration, direct integration into Android Studio, AOSP device emulators to get closer to your true target system, and the Esper Device SDK. What is this Device SDK, you say? As the system Device Owner, Esper has access to privileged APIs most APKs (apps) don’t have access to.

A simple example of the kind of information we can access that your typical app can’t is the device serial number. In Google’s increasing drive to protect consumer privacy, with Android 10 access to device serial number by apps is no more — thus taking away the means to precisely align a specific device to a particular app installation. But our customers can use the Device SDK on Esper-provisioned devices to fetch the device serial number, enabling 1:1 coordination between your Cloud and your APK on every single device in your fleet. These capabilities are available on any AOSP or GMS (Google Mobile Services) device, and of course are built into our own Android-based OS.

Fine grained behaviors residing deep within the Android OS are also available for you to manipulate. Do you wish to have the system check in with an NTP service to set proper time zone? Robust behavior for automatic connection retry for flaky Wi-Fi scenarios commonly encountered in consumer deployments? We can open that up to your through what we can JSON Config as part of our provisioning process.

Our OS takes fine-tuning the experience to the next level. You can fully customize the behavior of the Android navigation bar, the permissions model, as well as system notifications. Crucially, you aren’t stuck with whatever your device maker has decided to do, or more likely, the decisions made by the vendor of the BSP they’ve chosen.

OOBE (out of box experience)

The consumer “out-of-box-experience” can make or break a customer relationship when ARR is the linchpin of your business model. Bad OOBE means doubt about creating a long-term monetized relationship with your company. Look, feel, sounds, workflow — all are really, really important.

For better or worse, the Android OS is fairly fixed in what you need to be able to most effectively do this. That would be the previously-mentioned Device Owner, and that’s what Esper becomes on your Android device. Device Owner (along with the fading Device Admin) was essentially created for corporate IT scenarios, but we’ve adapted it for enterprise dedicated device fleets quite well — and we are not alone in trying (noting: we think we are the best).

The process of onboarding these BYOD enterprise devices (typically, smartphones and tablets) is called provisioning. But have you ever seen the screen flow when an Android device is provisioned? The focus is on delivering information that speaks to stagers and technicians, loudly stating Esper (the Device Owner) is taking control — that’s what these type of customers want. If you want true consumer electronics quality for that experience, the brand of the infrastructure provider (that’s us!) needs to disappear. The information given to the consumer needs to be tightly defined and controlled (what the heck does “obtaining device owner” mean?). No permission requests or app picker should get in the way. The only decisions and input to be made have to be decided by the company, not by the infrastructure. That makes Android’s typically enterprise-driven approach an ugly duckling for the CE use case.

That’s why Esper has perfected a CE provisioning flow in our own Android-based OS. CE companies want to control the engagement with the customer out of the gate with graphics and videos that set the stage. The Esper brand is gone: User interaction is removed during the provisioning process using our serial number or IMEI driven, cloud-based Seamless Provisioning technology.

Doing this is a bit of an iterative grind, but that’s CE: As the designers who “own the customer experience” fidget with the OOBE to get it just right, we’re actively part of that process, and we know that’s what’s required to hit the mark. Your solution is our solution.

We can explain more directly, if you’re interested.

Evolving the experience

Notice how I’m not referring to any of this process as app or firmware updates? Because that’s now how you should view device experiences at the top-level as a CE company! Eventually, this will bubble down to operations, but the driver is the customer experience and monetization.

Still, one specific vector of consideration is firmware. Yes, you will need to update your firmware. If you happen to have decided to use firmware updates to be what determines how you progress your customer experience (I have one such Android CE device in my stable), you should first consider a few things.

• The industry is still stuck at implementing what’s called traditional firmware updates.
• This means that a differential OTA package is built, pushed to the device, and then that device enters into a mode where the update is applied.
• During this update time, the device is offline and unavailable for use.

This takes me back to my stable of Android CE devices. You really need to consider how you present and handle the firmware update process to your end users, lest you create dissatisfaction (which is never good for an ARR business).

Case in point: the device I’m referring to is a bike computer, and updating the firmware is always presented after bootup — which is exactly when I want to use it. I’ve made the mistake of installing the update and then sitting unhappily waiting for it to complete — I’m ready to ride! But if I skip it, there’s no reminder at the natural window to perform the update (which is when the ride is over). I think we can all agree that some sensitivity here would be appreciated.

But there’s a better way — Android A/B updates! This is a more recent addition to Android, wherein there are two partitions for the operating system, an ‘A’ and a ‘B.’ The currently installed OS build runs in one partition, and then an update is installed into the B behind the scenes — no user interruption. So instead of an installation, the firmware update is installed into the other partition while the device is idle, and when the user is ready, it’s just a simple reboot — installation is already complete. It also means you avoid the disastrous device brick, because A/B updates provide a built-in failsafe. If the update kills the system (which might otherwise cause a “bootloop”), the old firmware is still there as an automatic backup solution.

Still, there is no free lunch. The A/B implementation requires an increase in flash storage, therefore impacting the BOM cost. But this one time NRE cost increase can create a much more delightful customer experience compared to the traditional update route. Esper or not, you should consider moving to A/B updates if you haven’t already, even if you infrequently update your firmware. This is a major UX differentiator (in that your users will largely fail to notice it’s there — exactly what we want).

Esper’s own Android-based OS natively supports A/B updates (as well as traditional if you choose to go that route). With our built in OTA Manager tied to our cloud-based, DevOps-driven OTA build and delivery system, you can pipeline these changes out starting from your test lab. Then, you can move on to incremental full deployment, ensuring any field issues are addressed before the blast radius gets away from you.

If you use your APK as the means to drive the customer experience, we expect a fast pace of app development and deployment to be a key aspect of your business. This is Esper’s bread and butter. Through the same DevOps infrastructure with pipelines used for our OS OTAs, our cloud infrastructure can easily deploy apps for both AOSP and GMS-based devices, giving you maximum flexibility for your device fleet’s OS mix.

We also understand reality: Agile customers delivering fast-paced customer innovation don’t ship just one APK. Instead, they maintain a core release, typically indicated by version number, and then integrate permutations into this main release. Perhaps that’s different machine learning models for edge inference, different content packages, or market specific features — the possibilities are endless.

That’s where Esper’s support for build tags comes into play. You can maintain the same core version number for that APK, and manage the distribution of the permutations using the build tag mapped to either groups of devices or individually unique device IDs. And all of this can be driven and done via Esper’s Cloud API to achieve full automation integration.

Dealing with configuration changes

But what happens after your devices are out in the wild? Don’t kid yourself that your scope of evolving the experience is dependent on just your APK. System configurations set during provisioning may actually end up in the way of achieving the next notch of your experience evolution journey. What if you find that you need to change how you handle your USB policy on the device? Want to provide a different default screen brightness and sound? Find out you need to turn on data roaming based on a new capability from your data MVNO? No problem, use our namespace API for a staged, code-driven rollout to your fleet. All of this is built into Esper’s core management support, and it’s all configurable via our console or the aforementioned code-driven automation.

And if you encounter something you need to do but don’t know how, our CS team will get you there by blending our DevOps with your DevOps! In the final post of the series, we cover some of that by displaying some of the strategies you can implement to make sure you’re optimizing your time spent.

If this series has tickled your inner device maker, feel free to reach out — we can set up a demo, or just chat about what is you’re building.

‍