The digital signage industry appeared to have woken up suddenly in the past year to embrace Android as if it were the savior for us all. I recently had the chance to join Adrian Cotterill, editor-in-chief of DailyDOOH, at a digital signage seminar with 300-plus attendees. I nodded hard when I heard Adrian proclaiming that "launching an Android player is not innovation." Indeed, these days it is easy to find plenty of "free" digital signage apps available for download, and lots of cheap Android tablets, boxes, and sticks reviewed by digital signage bloggers. Is this really what the next-gen all about?
From the people I spoke to everywhere in our industry, it is surprising that a "good" Android player is hard to come by. It's not about the number of CPU cores or clock speed, I've learned. It's how well it meets the needs of industry applications. In a recent interview with David Keene, executive editor of Digital Signage Magazine, I shared my thoughts on Android. "There is of course a huge momentum for Android coming from the consumer market, but Android comes with a lot of challenges...[We] heavily modify the Android source code to make it more robust, and more secure."
I hope to share with you a few truths that lie underneath the surface of the new wave.
Why can't I deploy consumer tablets for digital signage?
Most people who tried piloting with consumer tablets are already convinced that they don't work. There are a few reasons why.
Consumer tablets are designed for portability and flexibility. Digital signage devices need to be vandal-proof and manageable. We are basically targeting two opposite extremes of the design spectrum. Android insists on displaying the "home menu" which occupies a rectangular area at the bottom of the screen, whereas we in digital signage want to use the entire screen real estate. Android tries hard to make sure the user always have access to the "home button" to gain control of the device, whereas in digital signage the device has to be "locked down" and secured to display only authorized content. The list goes on. I would not expect one day Google looks at our market and decides they should take our needs into consideration and change the design of Android.
During my company's journey in making our own Android device, it is not unusual that we find Google ignoring reported bugs if they didn't concern the average consumer. Let me give you an example.
HTML5 is the next frontier. But which HTML5?
At the seminar mentioned earlier, I had the privilege to speak about HTML5 and pointed out the long list of digital signage companies who have jumped on the bandwagon and announced support for HTML5, the standard for Web content. We were one of the earliest companies in the industry to announce an HTML5-compliant hardware product, and the first to hear the frustration when users found out their HTML5 Web page didn't always work across different Android devices.
Each version of Android (17 varieties since its launch in 2008, averaging about 3.5 new Android flavors introduced every year) comes with a different browser with a different personality, and none of these works the same way as your regular desktop browser. To run HTML5 content on Android requires understanding the limitations posed by the particular browser running on your Android device.
You may think that Android, having run on billions of devices to-date, must be solid and robust. It is true if you are only making a dozen phone calls a day or reading a handful of Web pages. If you try to play a loop of 15-second clips in your Android browser for 24x7 (that's equivalent to clicking the "play" button 1 million times a week), chances are many devices will crash in front of your unbelieving eyes. Throwing in a few animations, one customer of ours was able to consistently crash top-brand consumer Android tablets in a matter of minutes.
What about that $99 Android stick?
Typical low-cost Android devices use a single flash memory module that stores both your data and Android system software. It gets the cost down, but when you get a bad block (naturally occurring after a few months' use, faster if your content is more complex), you bring down the whole system and kill the device. Another design option calls for separate storage hardware for data and program, but it more than doubles the cost of hardware. However, when bad blocks happen due to content updates, the damage is limited to the data portion, will not crash the program portion nor kill the device, and can be automatically corrected. For the added cost, you save a few on-site visits during the lifetime of the device.
Another hardware feature that no consumer Android device employs is the hardware watchdog timer, or WDT. This is a component found only in industrial-grade PCs to protect a system from an unexpected crash and from getting stuck on the "blue screen of death." No common Android design includes the WDT (when your phone crashes, you just yank out the battery to restart it). A device needs a WDT to keep the system running even if it encounters serious system bugs.
Modifying Android to support large projects
For the customer looking to deploy two screens in his own store, where he can easily power on and off his device when it crashes, the typical Android device is probably good enough. I would think digital signage is much more than that, and the cost of maintenance is a huge factor for serious projects. If a customer gets one failure per month that requires a visit to the site, it represents a huge maintenance cost and is not acceptable by our industry standards.
For serious projects, the ease of deployment also matters. Installing an Android app requires no fewer than a dozen mouse clicks. By re-engineering Android, the process can be streamlined so any unskilled installer can finish the job by simply inserting a USB stick. Getting your software updated in the field without manual intervention can be quite difficult and requires a few software "hacks" that may not work on all devices. Again, by rebuilding part of Android, the system can provide an API that not only allows you to update your app, but even remotely refresh the entire firmware of the device should you ever need to upgrade to the latest Android operating system available.
Also, most Android tablets depend on a Wi-Fi network connection that can be fragile at times. For digital signage, reliability is key, so an Ethernet port must be available, but that introduces a second wire that can add serious complexity, potential point-of-failure, and cost to your project. A better design could incorporate the IEEE 802.3af power-over-Ethernet technology that delivers both networking and power in one wire.
So it appears picking an Android device for digital signage applications is a little bit more complicated than comparing CPU specs and OS versions. I hope the experience I've had will help you pick the right device for your next project.
John is CEO of IAdea Corp., and he actively drives open standards for digital signage at the World Wide Web Consortium (W3C) and POPAI, and chairs the Standards Committee at the Digital Signage and Multimedia Association.