Jun 22

Android Things client library for Google Cloud IoT Core


Posted by Wayne Piekarski, Developer Advocate for IoT +WaynePiekarski @WaynePiekarski

We’re releasing a client library to make it easy to use Google Cloud IoT Core from Android Things devices. With just a few lines of code, you can easily connect to the IoT Core MQTT bridge, authenticate the device, publish device telemetry and state, subscribe to configuration changes, and handle errors and network outages.

What is Cloud IoT Core?

Cloud IoT Core is a fully managed service on Google Cloud Platform that allows you to easily and securely connect, manage, and ingest data from millions of globally dispersed devices. Cloud IoT Core, in combination with other services which make up Google’s Cloud IoT platform, provides a complete solution for collecting, processing, analyzing, and visualizing IoT data in real time, to support improved operational efficiency, compliance, or revenue management. Android Things is designed to support everything from collecting telemetry data to powerful computer vision, audio processing, and machine learning applications, all on device, and using Cloud IoT Core, push your data into Google Cloud Platform for further analysis.

Cloud IoT Core client library

The Cloud IoT Core client library was designed to enable Android Things developers to get started with just a few lines of code. The client library handles the networking, threading, and message handling, implementing best practices for authentication, security, error handling, and offline operation.

Cloud IoT Core maintains a device registry that keeps track of approved devices, and each device uses a public key to authenticate with the server. Android Things provides many features to support secure IoT applications, including a hardware-backed Android Keystore that ensures cryptographic key material is protected. The client library supports both RSA and ECC keys, and implements the generation of JSON Web Tokens (JWTs) for authentication with Cloud IoT Core.

Once the connection is established, devices can publish their telemetry data to one or more buckets in the telemetry topic, as well as report their internal state to a separate device state topic. The device state is intended to store information such as software versions or the number of working sensors. The telemetry messages are for all other data from the device, such as actual sensor measurements. Devices can also subscribe to configuration changes published from Cloud IoT Core.

Because IoT devices operate in the real world with poor wireless conditions, the client library provides extensive support for handling errors, and for caching and retransmitting events later. For developers requiring custom offline behavior, the library’s queue is configurable and even replaceable. This provides detailed control over which events to save and the order in which they are sent when back online.

Device provisioning and authentication with Android Things

The Cloud IoT Core client library is part of our overall vision for device provisioning and authentication with Android Things. To learn more about this, watch the video of our presentation from Google I/O 2018:

Sample code

Getting started with the Cloud IoT Core client library is simple. You can simply add the following to the build.gradle file in your Android Things project:

implementation 'com.google.android.things:cloud-iot-core:1.0.0'

The library is also available as open source on GitHub if you prefer to build it yourself. We also have a sample that shows how to implement a sensor hub on Android Things, collecting sensor data from connected sensors and publishing them to a Google Cloud IoT Pub/Sub topic.

It is easy to start using the client library in your own code. The following Kotlin example demonstrates how to create a new configuration and client based on your project.

var configuration = IotCoreConfiguration.Builder().
                         .setProjectId("my-gcp-project")
                         .setRegistry("my-device-registry", "us-central1")
                         .setDeviceId("my-device-id")
                         .setKeyPair(keyPairObject)
                         .build()

var iotCoreClient = IotCoreClient.Builder()
              .setIotCoreConfiguration(configuration)
              .setOnConfigurationListener(onConfigurationListener)
              .setConnectionCallback(connectionCallback)
              .build()

iotCoreClient.connect()

Next, you can publish telemetry information or device state, using the following Kotlin examples.

private fun publishTelemetry(temperature: Float, humidity: Float) {
    // payload is an arbitrary, application-specific array of bytes
    val examplePayload = """{
        |"temperature" : $  temperature,
        |"humidity": $  humidity
        |}""".trimMargin().toByteArray()
    val event = TelemetryEvent(examplePayload, topicSubpath, TelemetryEvent.QOS_AT_LEAST_ONCE)
    iotCoreClient.publishTelemetry(event)
}

private fun publishDeviceState(telemetryFrequency: Int, enabledSensors: Array<String>) {
    // payload is an arbitrary, application-specific array of bytes
    val examplePayload = """{
        |"telemetryFrequency": $  telemetryFrequency,
        |"enabledSensors": $  {enabledSensors.contentToString()}
        |}""".trimMargin().toByteArray()
    iotCoreClient.publishDeviceState(examplePayload)
}

Additional resources

You can learn more about building for Android Things at the developer site. For more information about getting started with Cloud IoT Core, visit the information page and documentation. Finally, join Google’s IoT Developers Community on Google+ to let us know what you’re building with Android Things and Cloud IoT Core!


Android Developers Blog

May 26

All the (Android) Things at Google I/O


Melissa Daniels, Program Manager for Android Things

Android Things enables you to build and maintain IoT devices at scale. We recently released Android Things 1.0 with long-term support for production devices, so you can easily take an IoT device from prototype to commercial product.

We packed Google I/O this year with Android Things content to inspire and empower the developer community, from talks and codelabs to interactive demos and a scavenger hunt. Here’s a closer look at the fun stuff we had on display that you won’t see on the shelves of retail stores.

Demos

We introduced a handful of new interactive Android Things demos across I/O, showcasing the AI and ML capabilities of the platform, so if you didn’t get an opportunity to attend this year, here’s a few of our favorites– perfect for exploring from wherever you are in the world!

Smart Flowers: Flos Mobilis

What do you get when you combine machine learning, Android Things and robotics? Flos Mobilis, a continuum robot where each flower is backed by an i.MX7D development board and a camera to run an embedded neural net model that controls the motion of the flower. This is all done offline with no data stored or transmitted.

Smart Flowers: Flos Affectus

What if a robot could respond to the way you feel? Flos Affectus is a cluster of robotic flowers that “bloom” and “un-bloom” depending on the expression detected on the user’s face. The 4 broad expressions Flos Affectus is trained to detect are: happy, sad, angry, surprised. Using a camera embedded in the head of the alpha flower, the flower cluster is able to detect the user’s face and infer the facial emotion. The flower cluster runs offline with no data stored or transmitted and demonstrates movement capabilities and on-device machine learning models.

Rosie the Android

Initially designed by a team of Google engineers for the annual Grace Hopper conference, Rosie the Android is a 5 foot selfie-taking Android, complete with machine-learning capabilities. Inspired by Rosie the Riveter, she’s a fully controllable robot that can take photos, respond to commands, wheel around and interact with those around her.

Did you take a selfie with Rosie at I/O? Redeem your unique access code at g.co/rosie

Smart Projector

Smart Projector is built on Lantern, an Android Things project exploring the relationship between surfaces and content — augmenting real-world objects and environments with glanceable, meaningful data. It leverages the Google Experiments project known as Quick Draw, using the world’s largest doodling data set that has been shared publicly to help with machine learning research.

To learn more about Lantern or to start building your own, start here.

3D Printer

This modified Printrbot Smalls 3D Printer uses a real-time subsystem that showcases the flexibility of Android Things– a microcontroller does the low-latency motor control, while Android Things handles OpenGL rendering. By keeping most of the logic on a high-level platform like Android you make development and debugging much easier, thanks to Android’s great tooling.

The future of 3D printing? Making real-time control as easy and portable as the rest of Android Things.

Codelabs

Phew! That was just the tip of the demo iceberg. With so many demos and so many ways to use Android Things, it’s easy to start imagining all the things you can build! At I/O, we helped a lot of developers get started building their first Android Things device using the Android Things Starter Kit. We’re making these codelabs available, so you can get to them whenever you need, or build your own.

Videos

Missed the I/O talks? Catch the recordings of each Android Things talk, so you can start, pause, and rewind at your own leisure. Or, just lean back and watch them all.

What’s new in Android Things

Build effective OEM-level apps on Android Things

Build real consumer devices with Android Things

Electronic design for Android Things System on Modules

Women Techmakers panel: experiences developing on Android Things

Product design: how to build better products with Android Things

Device provisioning and authentication with Android Things

Update production devices in the field with the Android Things Console

Start building!

On top of all the resources we just mentioned, we have a corpus of information on our developer documentation, and our new community website where you can see more inspiring projects and even submit your own. So, what are you waiting for? Pick up an Android Things Starter Kit and start building something today!


Android Developers Blog

May 08

Say Hello to Android Things 1.0


Posted by Dave Smith, Developer Advocate for IoT

Android Things is Google’s managed OS that enables you to build and maintain Internet of Things devices at scale. We provide a robust platform that does the heavy lifting with certified hardware, rich developer APIs, and secure managed software updates using Google’s back-end infrastructure, so you can focus on building your product.

After a developer preview with over 100,000 SDK downloads, we’re releasing Android Things 1.0 to developers today with long-term support for production devices. Developer feedback and engagement has been critical in our journey towards 1.0, and we are grateful to the over 10,000 developers who have provided us feedback through the issue tracker, at workshop events, and through our Google+ community.

Powerful production hardware

Today, we are announcing support for new System-on-Modules (SoMs) based on the NXP i.MX8M, Qualcomm SDA212, Qualcomm SDA624, and MediaTek MT8516 hardware platforms. These modules are certified for production use with guaranteed long-term support for three years, making it easier to bring prototypes to market. Development hardware and reference designs for these SoMs will be available in the coming months.



New SoMs from NXP, Qualcomm, and MediaTek

The Raspberry Pi 3 Model B and NXP i.MX7D devices will continue to be supported as developer hardware for you to prototype and test your product ideas. Support for the NXP i.MX6UL devices will not continue. See the updated supported platforms page for more details on the differences between production and prototype hardware.

Secure software updates

One of the core tenets of Android Things is powering devices that remain secure over time. Providing timely software updates over-the-air (OTA) is a fundamental part of that. Stability fixes and security patches are supported on production hardware platforms, and automatic updates are enabled for all devices by default. For each long-term support version, Google will offer free stability fixes and security patches for three years, with additional options for extended support. Even after the official support window ends, you will still be able to continue to push app updates to your devices. See the program policies for more details on software update support.

Use of the Android Things Console for software updates is limited to 100 active devices for non-commercial use. Developers who intend to ship a commercial product running Android Things must sign a distribution agreement with Google to remove the device limit. Review the updated terms in the Android Things SDK License Agreement and Console Terms of Service.

Hardware configuration

The Android Things Console includes a new interface to configure hardware peripherals, enabling build-time control of the Peripheral I/O connections available and device properties such as GPIO resistors and I2C bus speed. This feature will continue to be expanded in future releases to encompass more peripheral hardware configurations.

Production ready

Over the past several months, we’ve worked closely with partners to bring products built on Android Things to market. These include Smart Speakers from LG and iHome and Smart Displays from Lenovo, LG, and JBL, which showcase powerful capabilities like Google Assistant and Google Cast. These products are hitting shelves between now and the end of summer.

Startups and agencies are also using Android Things to prototype innovative ideas for a diverse set of use-cases. Here are some examples we are really excited about:

  • Byteflies: Docking station that securely transmits wearable health data to the cloud
  • Mirego: Network of large photo displays driven by public photo booths in downtown Montreal

If you’re building a new product powered by Android Things, we want to work with you too! We are introducing a special limited program to partner with the Android Things team for technical guidance and support building your product. Space is limited and we can’t accept everyone. If your company is interested in learning more, please let us know here.

Additional resources

Take a look at the full release notes for Android Things 1.0, and head over to the Android Things Console to begin validating your devices for production with the 1.0 system image. Visit the developer site to learn more about the platform and explore androidthings.withgoogle.com to get started with kits, sample code, and community projects. Finally, join Google’s IoT Developers Community on Google+ to let us know what you’re building with Android Things!


Android Developers Blog

Apr 17

Android Things Release Candidate


Posted by Dave Smith, Developer Advocate for IoT

Earlier this year at CES, we showcased consumer products powered by Android Things from partners like Lenovo, LG, JBL, iHome, and Sony. We are excited to see Android Things enable the wider developer ecosystem as well. Today we are announcing the final preview release of Android Things, Developer Preview 8, before the upcoming stable release.

Feature complete SDK

Developer Preview 8 represents the final API surface exposed in the Android Things support library for the upcoming stable release. There will be no more breaking API changes before the stable v1.0 release of the SDK. For details on all the API changes included in DP8, see the release notes. Refer to the updated SDK reference to review the classes and methods in the final SDK.

This release also brings new features in the Android Things developer console to make building and managing production devices easier. Here are some notable updates:

Production-focused console enhancements

With an eye towards building and shipping production devices with the upcoming LTS release, we have made several updates to the Android Things developer console:

  • Enhanced OTA: Unpublish the current OTA build when issues are discovered in the field.
  • Visual storage layout: Configure the device storage allocated to apps and data for each build, and get an overview of how much storage your apps require.
  • Font/locale controls: Configure the set of supported fonts and locales packaged into each build.
  • Group sharing: Product sharing has been extended to include support for Google Groups.

App library

The new app library enables you to manage APKs more easily without the need to package them together in a separate zipped bundle. Track individual versions, review permissions, and share your apps with other console users. See the app library documentation for more details.

Permissions

On mobile devices, apps request permissions at runtime and the end user grants them. In earlier previews, Android Things granted these same permissions automatically to apps on device boot. Beginning in DP8, these permissions are granted using a new interface in the developer console, giving developers more control of the permissions used by the apps on their device.

This change does not affect development, as Android Studio grants all permissions by default. Developers using the command line can append the -g flag to the adb install command to get the same behavior. To test how apps on your device behave with certain permissions revoked, use the pm command:

$   adb shell pm [grant|revoke] <permission-name> ...

App launch behavior

Embedded devices need to launch their primary application automatically after the device boots, and relaunch it if the app terminates unexpectedly. In earlier previews, the main app on the device could listen for a custom IOT_LAUNCHER intent to enable this behavior. Beginning in DP8, this category is replaced by the standard CATEGORY_HOME intent.

<activity android:name=".HomeActivity">
    ...

    <!-- Launch activity automatically on boot, relaunch on termination. -->
    <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>

Apps that contain an IOT_LAUNCHER intent filter will no longer be triggered on boot. Update your apps to use CATEGORY_HOME instead.

Feedback

Thanks to all of you in the developer community for sharing your feedback with us throughout developer preview. Join Google’s IoT Developers Community on Google+ to let us know what you’re building with Android Things and how we can improve the platform in future releases to help you build connected devices at scale!


Android Developers Blog

Mar 07

Android Things Developer Preview 7

Posted by Dave Smith, Developer Advocate for IoT

Today we’re releasing Developer Preview 7 (DP7) of Android Things, Google’s platform that enables Android developers to create Internet of Things (IoT) devices. The platform also supports powerful applications such as video and audio processing and on-board machine learning with TensorFlow.

The latest preview is based on Android 8.1 and is updated to support version 11.8.0 of Google Play Services. For all the details of what’s included in DP7, see the release notes. Here are some of the highlights:

Console enhancements and device updates

New features are also available in the Android Things Console to enhance product management from prototype to production:

  • Product Models. Create multiple software variations of the same hardware product, and manage the builds and updates for each independently.
  • Product Sharing. Grant additional user accounts access to view and manage the models, builds, and updates for a given product.
  • Analytics. View metrics on device activations and update statistics for your products.
  • Update Channels. Deploy software builds to groups of devices for development or beta testing, without disrupting production devices in the field.

Devices can subscribe to different update channels using new APIs added to UpdateManager. See the updated Device Updates API guide and console documentation to learn more about configuring update channel subscriptions.

Addressing developer feedback

We’ve received tons of amazing feedback from developers so far, and focused heavily on addressing many of the top reported issues in this release:

  • Improved camera resolution support. Apps can now capture image data up to the full native resolution of the camera hardware.
  • Support for MIDI. Use the MidiManager API to build a virtual MIDI device in your app or interface with external MIDI controllers.
  • Better testability of Android Things apps. The Peripheral I/O API now exposes interfaces instead of abstract classes, allowing local unit tests to replace these objects with mocks and stubs more easily.
  • Consistent API naming. This release renames many of the existing Android Things API classes to provide a more consistent developer experience across the entire surface. See the updated API reference to review how package and class names have changed.

New Bluetooth APIs

Android mobile devices expose controls to users for pairing with and connecting to Bluetooth devices through the Settings app. IoT devices running Android Things need to programmatically perform these same operations. The new BluetoothConnectionManager API enables apps to take control of the pairing and connection process. See the new Bluetooth API guide for more details.

Sample updates

Last year at Google I/O, we demonstrated building an app using Kotlin on Android Things. For developers using Kotlin, we have started publishing Kotlin versions of the Android Things samples. Today you can download the Button and LED sample in both Kotlin and Java, with more samples to follow very soon.

We have also migrated the TensorFlow Image Classifier sample app to use the TensorFlow Lite library, reducing the size of the pre-trained TensorFlow model by over 90% and the time required to classify the images by approximately 50%.

Feedback

Please send us your feedback by filing bug reports and feature requests, as well as asking any questions on Stack Overflow. You can also join Google’s IoT Developers Community on Google+, a great resource to get updates and discuss ideas. We look forward to seeing what you build with Android Things!


Android Developers Blog

Jan 09

New Products At CES powered by Android Things

By Venkat Rapaka, Director of Product Management, Google

The Android Things team has been working closely with our partners to create
compelling, secure and thoughtful IoT products. During the Consumer Electronics
Show (CES) in Las Vegas, a number of our OEM partners are announcing their first
set of products powered by Android Things. These products are built on certified
Android Things System-on-Modules (SoMs) from our silicon partners, benefit from
regular feature and security updates from Google, and have the Google Assistant
and Google Cast seamlessly built in.

Today, we also announced that the Google Assistant is coming to smart displays powered by
Android Things. These new devices have the Assistant and Cast built in, and with
the added benefit of a touch screen, they can help you see and do more. Smart
displays from JBL, Lenovo,
LG (all based on the Qualcomm SD624 Home Hub Platform) and S

Today, we also announced that the Google Assistant is coming to smart displays powered by
Android Things. These new devices have the Assistant and Cast built in, and with
the added benefit of a touch screen, they can help you see and do more. Smart
displays from JBL, Lenovo,
LG (all based on the Qualcomm SD624 Home Hub Platform) and Sony (based on the
MediaTek MT8173 SoM) will be available later this year.

Of course, Android Things is designed to support a wide variety of devices
beyond speakers and smart displays. Prototype demos can be found in the NXP
booth, such as HandBot, DrawBot,
3D printer, and AI artwork T-shirts.

Starting tomorrow, you can visit the Google Assistant Playground (booth CP-21)
at CES to view new products, chipsets, and reference designs by our partners. In
addition, these devices are also available for display in other company spaces
throughout the conference, including Lenovo, LG, JBL, Qualcomm, MediaTek, NXP,
Rockchip, iHome, Goertek, and Tymphany.

Android Things is currently in Developer Preview, and you can get started with
the latest version DP6.1. You can use the Android Things Console to
download system images and flash existing devices. Feedback can be given by
filing bug
reports and feature
requests, as well as on Stack
Overflow or our Google’s IoT Developers
Community. The Long Term Support release will be available this year, with
more details coming soon.


Android Developers Blog

Dec 15

LoWPAN on Android Things

Posted by Dave Smith,
Developer Advocate for IoT

Creating robust connections between IoT devices can be difficult. WiFi and
Bluetooth are ubiquitous and work well in many scenarios, but suffer limitations
when power is constrained or large numbers of devices are required on a single
network. In response to this, new communications technologies have arisen to
address the power and scalability requirements for IoT.

Low-power Wireless Personal Area Network (LoWPAN) technologies are specifically
designed for peer-to-peer usage on constrained battery-powered devices. Devices
on the same LoWPAN can communicate with each other using familiar IP networking,
allowing developers to use standard application protocols like HTTP and CoAP.
The specific LoWPAN technology that we are most excited about is Thread: a secure,
fault-tolerant, low-power mesh-networking technology that is quickly becoming an
industry standard.

Today we are announcing API support for configuring and managing LoWPAN as a
part of Android Things Developer Preview 6.1, including first-class networking
support for Thread. By adding an 802.15.4 radio module to one of our developer
kits, Android Things devices can communicate directly with other peer
devices on a Thread network. These types of low-power connectivity solutions
enable Android Things devices to perform edge computing tasks,
aggregating data locally from nearby devices to make critical decisions without
a constant connection to cloud services. See the LoWPAN API guide
for more details on building apps to create and join local mesh networks.

Getting Started

OpenThread makes getting started with LoWPAN
on Android Things easy. Choose a supported radio platform, such as the Nordic nRF52840, and
download pre-built
firmware to enable it as a Network Co-Processor (NCP). Integrate the radio
into Android Things using the LoWPAN
NCP user driver. You can also expand support to other radio hardware by
building your own user drivers. See the LoWPAN user driver
API guide for more details.

To get started with DP6.1, use the Android Things Console to
download system images and flash existing devices. Then download the LoWPAN sample app to try it
out for yourself! LoWPAN isn’t the only exciting thing happening in the latest
release. See the release
notes for the full set of fixes and updates included in DP6.1.

Feedback

Please send us your feedback by filing bug
reports and feature
requests, as well as asking any questions on Stack
Overflow. You can also join Google’s IoT
Developers Community on Google+, a great resource to get updates and discuss
ideas. Also, we have our new hackster.io
community, where everyone can share the amazing projects they have built. We
look forward to seeing what you build with Android Things!


Android Developers Blog

Dec 01

Android Things Developer Preview 6

Posted by Wayne Piekarski,
Developer Advocate for IoT

The next release of Android Things Developer Preview 6 (DP6) is here with lots
of new features and bug fixes. Android Things is Google’s platform that enables
Android Developers to create Internet of Things (IoT) devices with support for
powerful applications such as video and audio processing and on-board machine
learning with TensorFlow. For the specifics on what is new, visit the release
notes. Here are a few of the highlights of what is in DP6.

IoT launcher

DP6 includes a new IoT launcher that allows the user to see the current state of
the device and change settings using a touch screen or USB input devices.
Settings such as configuring the WiFi, finding the build ID, and checking for
updates is now something that can be done interactively, making it even easier
to get started. This launcher is visible when no other developer-provided IOT_LAUNCHER
Activity is present.

Graphics acceleration defaults

Android Things uses the open-source SwiftShader library, a
CPU-based implementation of the OpenGL ES APIs. This enables common OpenGL
support across all platforms, even those with no GPU hardware. However, many
simple 2D UIs render faster if the drawing is done directly to the framebuffer
and OpenGL emulation is not used. In DP6, OpenGL rendering is disabled by
default to ensure that most apps run with the fastest UI possible. If you need
OpenGL support for 3D rendering, WebView, or TextureView, then explicitly enable
it in your AndroidManifest.xml according to the documentation:

<activity

    ...
    android:hardwareAccelerated="true">

API 27 and Google Play Services

DP6 is now based on the latest Android 8.1 developer preview, with API level 27.
Most of the standard Android samples now work on DP6. For example, the Camera2Basic
sample using the Camera2 API and TextureView now works on both NXP and Raspberry
Pi based devices (with the hardwareAccelerated flag set to true). Google Play
Services has been updated to support SDK version 11.6, supporting all the latest
features.

Command-line flashing tool

We heard from developers that flashing and configuring a board using fastboot
can be tedious, so the Android Things
Console now brings a new and simpler way of flashing device images. Instead
of using fastboot and adb commands manually, a new interactive command-line
android-things-setup-utility
is now provided. This tool makes it much easier to get started with Android
Things, and automates the download and flashing process.

Android Things Console updates

DP6 introduces the new partition scheme that will be used for the upcoming
production release. Due to the new partition layout, the over-the-air update
(OTA) system cannot update existing DP5.1 or earlier devices. Developers will
need to go to the Android
Things Console, and download and flash a new DP6 build. The Console UI has
also been changed for DP6 features, and will only allow you to create new builds
based on DP6. If you have any older existing builds, they are still available
for download but will not support OTA updates. Developers are encouraged to move
all work to DP6.

GPIO pin naming

The interactive IoT launcher shown at boot now includes an I/O pinout section
where you can discover the labels of all the pins. The pin naming used by the
i.MX7 has been changed, and you should update your code to use this new naming
convention. See the i.MX7
documentation for the complete list of pin names.

Settings and Device Update APIs

New APIs have been added to Android Things that control the configuration
of the local device and device updates. UpdateManager
gives developers control over when updates and reboots can be performed,
ensuring the device is available for the user when needed. DeviceManager
controls factory reset, reboot, and device locales. APIs are also provided for
settings such as ScreenManager
to control the screen, and TimeManager
to control the clock and time zone.

Peripheral command-line tool

We now provide a command-line tool pio
that gives developers access to the Peripheral API via the adb shell. Developers
can interactively test GPIO, PWM, UART, I2C, SPI, and future interfaces from an
adb shell, which is useful for debugging and automated testing.

Feedback

DP6 includes significant changes and improvements to the platform. Please send
us your feedback by filing bug
reports and feature
requests, as well as asking any questions on Stack
Overflow. To start using DP6, use the Android Things Console to
download system images and flash existing devices, or use the android-things-setup-utility.
More information about the changes are available in the release
notes. You can also join Google’s IoT
Developers Community on Google+, a great resource to get updates and discuss
ideas. Also, we have our new hackster.io
community, where everyone can share the amazing projects they have built. We
look forward to seeing what you build with Android Things!


Android Developers Blog

Nov 18

Android Things Contest Winners







Posted by Dave Smith,
Developer Advocate for IoT

Back in September, we worked
with Hackster.io to encourage the developer community to build smart
connected devices using Android Things and post their projects to the Developer Challenge for Android
Things. The goal was to showcase the combination of turnkey hardware and a
powerful SDK for building and maintaining devices at scale.

Thank you to everyone who participated in the contest and submitted a project or
idea. We had over 1100 participants register for the contest, resulting in over
350 submissions. Out of that group, we’ve chosen three winners. Each winner will
receive support and tools from Dragon Innovation to develop their
concepts into commercial products. Join us in congratulating the following
makers!

Best Enterprise Project: Distributed
Air Quality Monitoring

Maker: James
Puderer

Monitor air quality on a street-by-street level using Android Things, Google
Cloud IoT Core, and taxis!

This project showcases how Android Things makes it easy to build devices that
integrate with the various services provided by the Google Cloud Platform for
robust data collection and analysis. It’s a clever end-to-end solution that
shows understanding of both the problem domain as well as the technology.

Best Start Up Project: BrewCentral

Maker: Trent Shumay and Steven Pridie

Brewing amazing beer is a balance of art, science, and ritual. The
BrewCentral system makes it possible for anyone to do an all-grain brew!

BrewCentral pairs a real-time PID controller with the touch-enabled UI and
decision-making compute power of Android Things. The result is a system that
accurately controls the time, temperature, and flow rates necessary to achieve
repeatable results during a brew cycle. The planned enhancements for cloud-based
brewing recipes will make this a connected experience for the entire brewing
community.

Best IoT Project: BrailleBox
- Braille News Reader

Maker: Joe Birch

BrailleBox is a small piece of hardware that empowers users who are
hard-of-sight to read the latest news articles in Braille.

This project is a great use case of using IoT to have a social impact. The
current proof of concept streams articles from a news feed to the Braille pad,
but this project has the potential to leverage machine learning on the device to
translate additional input from the physical world into a Braille result.

Honorable Mentions

The community submitted some amazing projects for the contest, which made the
choice of picking only three winners extremely difficult. Here are a few of our
favorite projects that weren’t selected for a prize:

  • Andro
    Cart: A shopping cart device powered by Android Things. Designed to help
    decentralize point of sale (POS) billing.

  • SIGHT:
    For the Blind: A pair of smart glasses for the blind, powered by Android
    Things and TensorFlow.

  • Industrial
    IoT Gateway: A smart industrial gateway for the IoT world based on Android
    Things.

  • Sentinel: The
    first semi-autonomous home security robot based on Android Things.

  • Word
    Clock: A creative take on reading the time, powered by Android Things.
    Control it via the Nearby API or the Google Assistant.

We encourage everyone to check out all the new projects in the Google
Hackster community, and submit your own as well! You can also join Google’s IoT Developers Community on Google+, a
great resource to get updates, ask questions, and discuss ideas. We look forward
to seeing what exciting projects you build!


Android Developers Blog

Nov 14

10 things you might be doing wrong when using the SafetyNet Attestation API

Posted by Oscar Rodriguez, Developer Advocate

The
SafetyNet Attestation API helps you assess the security and compatibility of
the Android environments in which your apps run. Since it was introduced in
March 2015, many developers have successfully integrated it into their Android
apps to make more informed decisions based on the integrity and compatibility of
the devices running their apps.

Throughout the years, the SafetyNet Attestation API has evolved, and its
adoption has steadily increased. However, as with any security/anti-abuse
related API, there are many common pitfalls that may lead developers into
developing unstable systems, or worse, into a false sense of security.

In this post, we provide a list of the most common mistakes we have seen
developers make when integrating the SafetyNet Attestation API.

1. Not getting an API key

Just like many other Google APIs, the SafetyNet Attestation API requires an API
key in order to run. Furthermore, the SafetyNet Attestation API has a per-key
usage quota. Although you can get this quota increased, you need to provide your
API key to do so.

Getting an API key is easy and free of charge. There is no reason not to get an
API key, so if you haven’t already, get
an API key now.

2. Not using the latest version of the API

The SafetyNet Attestation API has evolved throughout its history, and with it,
there have been some interface changes. Most recently, with the release of
Google Play services 11.0.0, we revamped the entire SafetyNet API to offer an
interface that is easier and more streamlined to use: the new API uses SafetyNetClient
instead of SafetyNetApi,
which is now deprecated, so make sure you update your implementation to use the
latest version of the API.

Most devices should have the latest version of Google Play services installed,
but if a device doesn’t have Google Play services installed, or doesn’t have it
up to date, using the SafetyNet Attestation API may lead to the app becoming
unresponsive or crashing. You can prevent this by checking
the installed version of Google Play services before using the API.

3. Using nonces incorrectly

The SafetyNet Attestation API lets you set a nonce to uniquely and globally
identify each call to the API. Use this feature to prevent a malicious user from
reusing a successful attestation result in place of an unsuccessful result (also
known as a Replay
Attack
).

One
good way to create a nonce is to create a large (16 bytes or longer) random
number on your server using a cryptographically-secure random function. The
SafetyNet attestation response includes the nonce you set, so make sure you
verify that the returned nonce matches the one you included in the request you
made.

4. Not checking the results on your server

SafetyNet can provide useful signals about the state of the device in which your
app is running. However, if the logic that acts on these signals is only
implemented and enforced directly on the device, an attacker could be able to
modify your app and bypass any checks you perform.

To prevent this situation, you should run any logic that verifies the
attestation result and enforces any actions based on them on a server that you
control and trust.

5. Using the test attestation verification service for production

In order to simplify development and testing of the SafetyNet Attestation API,
Google offers an online
verification service that checks the digital signature of a SafetyNet
Attestation result using a simple HTTPS request.

As useful as this service may seem, it is designed for test purposes only, and
it has very strict usage quotas that will not be increased upon request.
Instead, you should implement the digital signature verification logic on your
server in a way that it doesn’t depend on Google’s servers. Most JWT libraries
offer signature verification functionality, and we have code samples
that show how to perform this verification in Java and C#. We plan to provide
samples for more languages in the future.

6. Not checking the nonce, timestamp, APK name, and hashes

The SafetyNet Attestation API is most widely known for its integrity and
compatibility checks, whose results are returned in ctsProfileMatch
and basicIntegrity. Although these two values are indeed very
useful, you should check the other values in the response, as they contain
important information as well.

Use nonce to match a response to its request,
as explained above, and use timestampMs to check how much time has passed since you made the
request and you got the response. A delayed response that arrives several hours
or days after the request may suggest suspicious activity.

Use apkPackageName to check the name of the APK that made the
attestation request, and match apkDigestSha256 and
apkCertificateDigestSha256 to those from your app’s signed APK in
Google Play, to get a signal about the integrity of the installed app.

Remember that the trustworthiness of the response as a whole is tied to the
results of ctsProfileMatch and basicIntegrity. It is
not unthinkable for a compromised device that fails basicIntegrity
to have forged the rest of the values in the response.

7. Not understanding the differences between ctsProfileMatch
and basicIntegrity

The SafetyNet Attestation API initially provided a single value called
basicIntegrity to help developers determine the integrity of a
device. As the API evolved, we introduced a new, stricter check whose results
appear in a value called ctsProfileMatch, which allows developers
to more finely evaluate the devices on which their app is running.

In broad terms, basicIntegrity gives you a signal about the general
integrity of the device and its API. Rooted devices fail
basicIntegrity, as do emulators, virtual devices, and devices with
signs of tampering, such as API hooks.

On the other hand, ctsProfileMatch gives you a much stricter signal
about the compatibility of the device. Only unmodified devices that
have been certified by Google can pass ctsProfileMatch. Devices
that will fail ctsProfileMatch include the following:

  • Devices that fail basicIntegrity
  • Devices with an unlocked bootloader
  • Devices with a custom system image (custom ROM)
  • Devices for which the manufactured didn’t apply for, or pass, Google
    certification

  • Devices with a system image built directly from the Android Open Source Program source files
  • Devices with a system image distributed as part of a beta or developer
    preview program (including the Android Beta Program)

8. Not having a strategy for timing attestation checks

The SafetyNet Attestation API gives you a snapshot of the state of a device at
the moment when the attestation request was made. A successful attestation
doesn’t necessarily mean that the device would have passed attestation in the
past, or that it will in the future.

Because an attestation is just a spot check, you should plan a sensible strategy
for choosing when to make attestation requests. You may choose to require
successful attestations before users make in-app purchases, after a certain
number of days have passed since the last successful attestation, each time your
app is launched, after every reboot, or any other strategy that makes sense for
your app.

Keep in mind that an attestation request is computationally expensive, consumes
battery and bandwidth, and uses your quota. We recommend you plan a strategy to
use the least amount of attestations required to satisfy your use case.

9. Using the SafetyNet Attestation API results as the only signal
to attack abuse

It may be tempting to think that the SafetyNet Attestation API provides all the
necessary signals for protecting an app against abusers, and use it as the only
signal for building an anti-abuse system.

The SafetyNet Attestation API can only give signals about the state of
a device, not the intent of a user, which is what an anti-abuse system
should be designed to detect. Therefore, you might want to consider including
other signals, such as access logs and behavioral patterns, to more accurately
detect abusive users, and consider not blocking users solely on a failed
attestation. Furthermore, there are many other conditions that cause an
attestation to fail, such as network connection problems, quota issues, and
other transient problems.

In other words, not all users who fail attestation are necessarily abusers, and
not all abusers will necessarily fail attestation. By blocking users solely on
their attestation results, you might be missing abusive users that don’t fail
attestations. Furthermore, you might also be blocking legitimate, loyal
customers who fail attestations for reasons other than abuse.

10. Not monitoring and managing your usage quota

As mentioned before, the
SafetyNet Attestation API is rate limited, and there is a default quota of
10,000 requests per day for each API key. Although this quota might be enough
for most development, testing, and initial app launches, your app might reach
the default limit as it increases in popularity.

To prevent inadvertently reaching your quota and getting attestation errors, you
should build a system that monitors your usage of the API and warns you well
before you reach your quota so you can get it increased. You should also be
prepared to handle attestation failures because of an exceeded quota and avoid
blocking all your users in this situation.

If you are close to reaching your quota, or expect a short-term spike that may
lead you to exceed your quota, you can submit
this form to request short or long-term increases to the quota for your API
key. This process, as well as the additional quota, is free of charge.


Android Developers Blog