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.
The Bluetooth API enables access to the pairing and connection process for remote devices, and the configuration of Bluetooth system settings.
Device Updates API
The Device Updates API allows an application to control and monitor applying over the air (OTA) software updates to the device.
The Low-Power Wireless Personal Area Networks (LoWPAN) APIs enable apps to interact with local devices connected over a wireless personal area network.
The Native Development Kit (NDK) APIs enable you to write applications using C/C++, or integrate existing C/C++ code with an Android Things app.
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.
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.
Android Things uses three different settings APIs to control settings for the screen (display), system time, and available locales.
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 CATEGORY_DEFAULT and CATEGORY_HOME.
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, and re-launch if the app terminates. --> <intent-filter> <action android:name="android.intent.action.MAIN"/> <category android:name="android.intent.category.HOME"/> <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:
1. Does not include the open source FirebaseUI Auth component.
2. Does not include modes which require the user content dialog.
Each release of Android Things bundles the latest stable version of Google Play Services, and requires at least version 11.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.
Declare permissions that you need in your app's manifest file.
The granting of app permissions is done differently for Android Things than for typical Android apps since many IoT applications do not require a user interface or input device. Permissions are granted using Android Studio or the Android Things Console.
When running an app from Android Studio, all permissions (including dangerous permissions)
are granted at install time. This applies to new app installs and updated
<uses-permission> elements in existing apps. You can use the
adb tool to
grant or revoke permissions for testing.
When you are ready to distribute your apps using the Android Things Console, you grant the dangerous permissions (instead of the end user) for all apps as part of the build creation process. You can override this during development, but not on actual products; end users cannot modify these permissions.