Top 10 drivers for embedded Android
There will be 115 Google Android phones on the market by the end of 2010, along with 50 non-phone Android devices, according to Jason Schwarz in his investment newsletter, Economic Weather Station. Whether these figures are accurate, the reality is that Android is beginning to move beyond its beginnings in the smartphone form factor to a broad range of embedded devices that span multiple industries and segments.
Why are product managers and chief technology executives making the move to this white-hot platform? Why is Android an attractive technology for such diverse needs as medical devices, set-top boxes, and automotive infotainment systems? There are at least 10 good reasons, five of which are business drivers and five technical drivers.
Business requirements, especially in the context of technology available under an open-source license, can be compelling for both technology managers and corporate executives. This list is not meant to reflect all Android drivers but certainly some compelling reasons for choosing embedded Android.
1. Licensing: Embedded system development using open-source technology requires that the developer/seller understands the licenses for embedded software components. Android is very attractive because all core packages are open sourced under the terms of the Apache 2.0 license, which allows the usage of the source code for both commercial and free open-source applications. If your team creates a modified version of the source code, it may not have to be licensed under the terms of the original license.
2. Source code: Android provides a comprehensive set of source code, specifically created by the Android team, that leverages existing open-source projects to provide a complete and cohesive software stack. There are currently more than 200 separate Git trees in the public Android repository. Not only is there source for the core packages, but many hardware-component vendors have decided to provide source code for specific drivers. This source is also actively managed by a vibrant community. Clearly, this is a benefit for anybody wanting to optimize these components for a specific target.
Many existing embedded Linux development teams will also find the external packages, such as BlueZ, D-Bus, OpenSSL, and webkit, quite familiar because they are used by other open-source distributions. This reduces your team’s learning curve if you are new to Android and will help speed your development time.
3. Release cadence: Android has a relatively frequent cadence for major releases. Its heritage in the mobile world mandates a much more rapid release cycle, with multiple releases per year being quite common now. While Android seems to be settling in on a biannual release cycle, this rate of innovation can clearly benefit the Android adopter. With new feature support added quite frequently, you may have less to build by yourself and more options from which to select when building your project.
4. Ecosystem support: While the ARM architecture was the focus of most early Android product efforts, virtually all major embedded silicon providers have created and actively maintain an Android base port. These hardware providers are helping speed your time-to-market and are opening up their architectures for you to take advantage.
There is also a large developer community associated with Android, driving not only application layer content (more than 40,000 applications are available), but also Android middleware components, from both augmentation and optimization perspectives. This is critically important for the continued evolution of Android.
5. Documentation and training: The time it takes for your engineering team to become proficient in Android is not free. Clear, concise, up-to-date documentation is critical to get your team enabled. The Android community offers a wide variety of instruction content, videos (some user-created, some from commercial vendors), extensive blogs, and independent companies providing Android academies, best practices, and tutorials.