Android Things makes developing connected embedded devices easy by providing the same Android development tools, best-in-class Android framework, and Google APIs that make developers successful on mobile.
Apps for embedded devices bring developers closer to hardware peripherals and drivers than phones and tablets. In addition, embedded devices typically present a single app experience to users. This document goes over the major additions, omissions, and differences between core Android development and Android Things.
Android Things extends the core Android framework with additional APIs provided by the Things Support Library. These APIs allow apps to integrate with new types of hardware not found on mobile devices.
The Android Things platform is also streamlined for single application use. System apps are not present, and your app is launched automatically on startup to immerse your users in the app experience.
Things Support Library
Peripheral I/O API
The Peripheral I/O APIs let your apps communicate with sensors and actuators using industry standard protocols and interfaces. The following interfaces are supported: GPIO, PWM, I2C, SPI, UART.
See the Peripheral I/O API Guides for more information on how to use the APIs.
User Driver API
User drivers extend existing Android framework services and allow apps to inject hardware events into the framework that other apps can access using the standard Android APIs.
See the User Driver API Guides for more information on how to use the APIs.
Core application packages
Android Things doesn't include the standard suite of system apps and content providers. Avoid using common intents as well as the following content provider APIs in your apps:
Displays are optional
Android Things supports graphical user interfaces using the same UI toolkit available to traditional Android applications. In graphical mode, the application window occupies the full real estate of the display. Android Things does not include the system status bar or navigation buttons, giving applications full control over the visual user experience.
However, Android Things does not require a display. On devices where a graphical display is not present, activities are still a primary component of your Android Things app. This is because the framework delivers all input events to the foreground activity, which has focus. Your app cannot receive key events or motion events through any other application component, such as a service.
Home activity support
Android Things expects one application to expose a "home activity" in its manifest
as the main entry point for the system to automatically launch on boot. This
activity must contain an intent filter that includes both
For ease of development, this same activity should include a CATEGORY_LAUNCHER intent filter so Android Studio can launch it as the default activity when deploying or debugging.
<application android:label="@string/app_name"> <activity android:name=".HomeActivity"> <!-- Launch activity as default from Android Studio --> <intent-filter> <action android:name="android.intent.action.MAIN"/> <category android:name="android.intent.category.LAUNCHER"/> </intent-filter> <!-- Launch activity automatically on boot --> <intent-filter> <action android:name="android.intent.action.MAIN"/> <category android:name="android.intent.category.IOT_LAUNCHER"/> <category android:name="android.intent.category.DEFAULT"/> </intent-filter> </activity> </application>
Support for Google services
Android Things supports a subset of the Google APIs for Android. The following table breaks down API support in Android Things:
Each release of Android Things bundles the latest stable version of Google Play Services, and requires at least version 10.0.0 of the client SDK. Android Things does not include the Google Play Store, which is responsible for automatically updating Play Services on the device. Because the Play Services version on the device is static, apps cannot target a client SDK greater than the version bundled with the target release.
Requesting Permissions at Runtime is not supported because embedded devices aren't guaranteed to have a UI to accept the runtime dialog. Declare permissions that you need in your app's manifest file. All normal and dangerous permissions declared in your app's manifest are granted at install time.