The latest Android and Google Play news for app and game developers.
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.
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.
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.
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:
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) }
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!
Posted by Vishwath Mohan, Security Engineer
To keep users safe, most apps and devices have an authentication mechanism, or a way to prove that you're you. These mechanisms fall into three categories: knowledge factors, possession factors, and biometric factors. Knowledge factors ask for something you know (like a PIN or a password), possession factors ask for something you have (like a token generator or security key), and biometric factors ask for something you are (like your fingerprint, iris, or face).
Biometric authentication mechanisms are becoming increasingly popular, and it's easy to see why. They're faster than typing a password, easier than carrying around a separate security key, and they prevent one of the most common pitfalls of knowledge-factor based authentication—the risk of shoulder surfing.
As more devices incorporate biometric authentication to safeguard people's private information, we're improving biometrics-based authentication in Android P by:
Currently, biometric unlocks quantify their performance today with two metrics borrowed from machine learning (ML): False Accept Rate (FAR), and False Reject Rate (FRR).
In the case of biometrics, FAR measures how often a biometric model accidentally classifies an incorrect input as belonging to the target user—that is, how often another user is falsely recognized as the legitimate device owner. Similarly, FRR measures how often a biometric model accidentally classifies the user's biometric as incorrect—that is, how often a legitimate device owner has to retry their authentication. The first is a security concern, while the second is problematic for usability.
Both metrics do a great job of measuring the accuracy and precision of a given ML (or biometric) model when applied to random input samples. However, because neither metric accounts for an active attacker as part of the threat model, they do not provide very useful information about its resilience against attacks.
In Android 8.1, we introduced two new metrics that more explicitly account for an attacker in the threat model: Spoof Accept Rate (SAR) and Imposter Accept Rate (IAR). As their names suggest, these metrics measure how easily an attacker can bypass a biometric authentication scheme. Spoofing refers to the use of a known-good recording (e.g. replaying a voice recording or using a face or fingerprint picture), while impostor acceptance means a successful mimicking of another user's biometric (e.g. trying to sound or look like a target user).
We use the SAR/IAR metrics to categorize biometric authentication mechanisms as either strong or weak. Biometric authentication mechanisms with an SAR/IAR of 7% or lower are strong, and anything above 7% is weak. Why 7% specifically? Most fingerprint implementations have a SAR/IAR metric of about 7%, making this an appropriate standard to start with for other modalities as well. As biometric sensors and classification methods improve, this threshold can potentially be decreased in the future.
This binary classification is a slight oversimplification of the range of security that different implementations provide. However, it gives us a scalable mechanism (via the tiered authentication model) to appropriately scope the capabilities and the constraints of different biometric implementations across the ecosystem, based on the overall risk they pose.
While both strong and weak biometrics will be allowed to unlock a device, weak biometrics:
These measures are intended to allow weaker biometrics, while reducing the risk of unauthorized access.
Starting in Android P, developers can use the BiometricPrompt API to integrate biometric authentication into their apps in a device and biometric agnostic way. BiometricPrompt only exposes strong modalities, so developers can be assured of a consistent level of security across all devices their application runs on. A support library is also provided for devices running Android O and earlier, allowing applications to utilize the advantages of this API across more devices .
Here's a high-level architecture of BiometricPrompt.
The API is intended to be easy to use, allowing the platform to select an appropriate biometric to authenticate with instead of forcing app developers to implement this logic themselves. Here's an example of how a developer might use it in their app:
Biometrics have the potential to both simplify and strengthen how we authenticate our digital identity, but only if they are designed securely, measured accurately, and implemented in a privacy-preserving manner.
We want Android to get it right across all three. So we're combining secure design principles, a more attacker-aware measurement methodology, and a common, easy to use biometrics API that allows developers to integrate authentication in a simple, consistent, and safe manner.
Acknowledgements: This post was developed in joint collaboration with Jim Miller
Posted by Larry Yang and Angela Ying, Product Managers, Google Play
Subscriptions on Google Play continue to see huge growth, with subscribers growing over 80% year over year. At I/O 2018, we announced several improvements we're making to the user experience to reduce barriers to subscription sign-up, and more tools to let you manage your business the way you want to.
While users derive a lot of value from their subscriptions, our research shows their fears of being "trapped" in a subscription without the ability to cancel or worry they'll lose track of how much they're spending create a hindrance to users signing up for your subscription apps. To address these fears, we recently launched a new subscriptions center, a one-stop shop for users to manage their subscriptions on Google Play.
Through the subscriptions center, users can:
In addition, if a user cancels a subscription, we will now trigger a cancellation survey to give developers feedback as to why the user is cancelling. Currently you can see the data from the cancellation survey by querying our server side API.
The new subscriptions center also has a "Get Started" link in the empty state that lets users discover subscription apps through curated and localized collections.
With the launch of the subscriptions center, we're also launching new deep links you can use to direct your users to manage their subscriptions from your app, over email or via the web. To implement, use the package name and SKU to construct the deep link, and then add the deep link as a button or link from anywhere in your app. View the Android Developers website for more information.
In addition to creating a better experience for users, we're also rolling out new tools that give you more flexibility in managing your business. One of the features we've heard requested most is price changes. Coming soon, you can easily ask users to accept a price change via the Google Play Console without having to set up a completely new SKU. Google Play will notify users of the change via emails, push notifications and in-app messaging, and if by renewal date the user hasn't agreed, we'll cancel their subscription. Sign up here if you are interested in participating in the early access program.
Other features we launched at I/O that help you better manage your subscription business include the ability to:
This is in addition to faster test renewals and flexible intro pricing we announced earlier this year.
To easily implement all of these, make sure you are using the Google Play Billing Library, which launched version 1.1 at I/O. The billing library is an abstraction layer on top of the AIDL file, and API updates are automatically picked up when you update your build dependency file the next time you compile your app. Price changes and upgrade/downgrade with the same expiration date are only available through the billing library. This will be the case for future launches as well.
We strongly believe that by building a great user experience, we build a high quality subscriber base. And by giving you tools and insights to better manage your business, you have the flexibility to do what is best for your business and your customers.
How useful did you find this blogpost?
★ ★ ★ ★ ★
In December last year we announced that we would be making updates to app security to help verify product authenticity from Google Play. We are now adding a small amount of security metadata on top of APKs to verify that the APK was distributed by Google Play.
One of the reasons we're doing this is to help developers reach a wider audience, particularly in countries where peer-to-peer app sharing is common because of costly data plans and limited connectivity.
In the future, for apps obtained through Play-approved distribution channels, we'll be able to determine app authenticity while a device is offline, add those shared apps to a user's Play Library, and manage app updates when the device comes back online. This will give people more confidence when using Play-approved peer-to-peer sharing apps.
This also benefits you as a developer as it provides a Play-authorized offline distribution channel and, since the peer-to-peer shared app is added to your user's Play library, your app will now be eligible for app updates from Play.
No action is needed by developers or by those who use your app or game. We're adjusting Google Play's maximum APK size to take into account the small metadata addition, which is inserted into the APK Signing Block. In addition to improving the integrity of Google Play's mobile app ecosystem, this metadata will also present new distribution opportunities for developers and help more people keep their apps up to date.
Posted by Patricia Correa, Director, Developer Marketing, Platforms & Ecosystems
The Android developer ecosystem is made up of exceptional individuals with different backgrounds, interests, and dreams. To celebrate the people who make up our community, starting today, and over the coming months, we'll be meeting with developers, founders, product managers, designers, and others from around the world to hear more about their passions and discover what they do when they step away from their computers.
Watch stories featuring adventurer Niek Bokkers from Polarsteps (Netherlands), artist Faith Ringgold from Quiltuduko (USA) and chair restorer Hans Jørgen Wiberg from Be My Eyes (Denmark). You can also read more about them and their apps on g.co/play/imakeapps.
We'd love to hear from you too. Use the hashtag #IMakeApps on your social channels, sharing the app or game you work on, your role in its creation, and an image that best depicts who you are outside of work. We will regularly select and share some of our favorites on our channels.
If you also want to get featured in an upcoming #IMakeApps film, tell us more about yourself and your app or game, by completing this self-nomination form.
Stay tuned for more #IMakeApps stories by following us on Twitter, YouTube and LinkedIn.
Posted by David Brazdil and Nicolas Geoffray, Software Engineers
In Android, we care immensely about providing the best experience to our users and our developers. With each OS release, new features enable you to provide amazing experiences for users; however, we noticed that some app developers have been using non-SDK interfaces, which leads to increased crashes for users and emergency rollouts for developers. We want to do better and need your help to ensure that Android is stable with each new OS.
Three months ago, we announced our plans to start restricting the usage of non-SDK interfaces in Android P. We know these restrictions can impact your release workflow, and we want to make sure you have the tools to detect usage of non-SDK interfaces, as well as time in your planning for adjusting to the new policies and for giving us feedback.
In the Developer Preview and Beta 1, we have provided ways for you to see the impact of these restrictions on your app. In the Developer Preview, use of restricted APIs show up in logs and toast messages, and in Beta 1, we provided a StrictMode policy that allows you to programmatically find these restrictions and do your own logging. For example:
We understand there can be multiple reasons apps want to use non-SDK interfaces, and ensuring your app will continue to work in Android P is important to us. Many of you have explained your use cases through our issue tracker (thank you!), and for most of these requests, we have lifted the restrictions on specific non-SDK interfaces for Android P by adding them to the greylist. In addition, our team has conducted static analysis on millions of apps and processed thousands of automated reports from internal and external beta testers. Through this analysis, we have identified additional non-SDK interfaces that apps rely on and added them to the greylist. For everything on the greylist, we will be investigating public SDK alternatives for future releases. However, it's possible we may have missed some non-SDK interface uses, so we have made the majority of them available for apps whose target SDK is Android Oreo or below.
In summary, apps running on Android P will be subject to restricted usage of non-SDK interfaces. If you are targeting Android P, the greylist shows the non-SDK interfaces that will still be available, while all other non-SDK interfaces will not be accessible. If you are targeting Android Oreo or below, most restrictions will not apply, but you will get logcat warnings if you are accessing non-SDK interfaces that are not in the greylist (note that users don't see such warnings).
Try out our new Beta 2 release and use StrictMode to detect your non-SDK interfaces usage. You should expect Beta 2 to closely match what the final release will implement for restricting non-SDK interface usages. Also, please take a look at our new FAQ, which we hope will answer any questions you have around the feature. If not, let us know!
Posted by Hoi Lam, Lead Developer Advocate, Wear OS by Google
From the outset of the Wear OS by Google developer preview, battery life has been a major focus area. When we talked to the developer community, the update that attracted the most feedback was the disabling of alarms and jobs for background apps. After listening to developer feedback and reviewing the battery statistics, we are reversing this change. This should be reflected in all connected Wear OS preview devices, so there is no need to reflash your device.
The decision came as we reviewed the feedback and saw that a strict on/off setting prevents reasonable usage and promotes anti-patterns. Going forward, we plan to leverage the App Standby Buckets feature in Android P to fine-tune a suitable setting for Wear OS devices. The exact setting for alarms and jobs for background apps is still being iterated on. Developers are advised to follow the best practices to make sure their apps behave well, whichever bucket the apps are in.
Another area that developers should pay attention to is the strengthening of input and data privacy for background apps in Android P. Depending on an app's requirements, developers may need to use a foreground service to enable access to the device sensor throughout the day.
We expect to provide more updates to this preview before the final production release. Please submit any bugs you find via the Wear OS by Google issue tracker. The earlier you submit them, the higher the likelihood that we can include the fixes in the final release.
Play Console
