The latest Android and Google Play news for app and game developers.
Starting today, you can download Android Studio 3.2 Beta. Previewed at Google I/O 2018, the latest release of the official Android IDE is focused on helping onboard you to all the new features launched around Google I/O -- Android JetPack, Android P Developer Preview, and the new Android App Bundle format. There are also several other exciting new features included in Android Studio 3.2 to accelerate your app development, such as Emulator Snapshots and the Energy Profiler.
As the usage of Android Studio has grown in the 3.5 years since version 1.0, we have also become increasingly obsessed with quality. We continue to invest in quality because we know that millions of app developers spend almost everyday in Android Studio and need a reliable set of tools. Stability, build times, and other quality work will be the primary focus for our next release once we finish Android Studio 3.2. We also did not want to wait, so we have made checkins to address memory leaks and performance issues as well as fixed more than 450 bugs. Thank you for the continued feedback and please keep it coming so we can focus on the areas you care about most in the next version of Android Studio. If want to try out the latest features, and assess the improvements in quality, you can download Android Studio on the beta release channel.
What is inside of Android Studio 3.2
Building on the canary release of Android Studio 3.2, the Beta release includes:
Build Android App Bundle
Android Emulator Snapshots
Energy Profiler
Check out the full write-up of all the major features organized by development flow listed below and on the canary blog:
Build
Optimize
Sessions at Google I/O '18
With the release of Android Studio 3.2 at Google I/O '18, the Android Studio team also presented a series of sessions about Android Studio. Watch the following videos to see the latest features in action and to get tips & tricks on how to use Android Studio:
An overview of all the recent features in Android Studio for Android app developers. The session includes demos and a tour de force presentation of relevant features that will accelerate developers' workflow on the latest Android APIs.
A deep dive into the new features of the Android build system.
This session covers the new features in ConstraintLayout 2.0, as well as the latest functionality added in Android Studio design tools, highlighting how to effectively take advantage of them for designing, prototyping, and building a graphical user interface application.
This talk demonstrates how to diagnose and troubleshoot performance problems with your app using Android Studio Profilers. It covers examples of how to use the CPU, memory, network profilers, and highlight what's new.
This session discusses in-depth what is happening to the various compilers used in Android: Java 8 language feature desugaring, the new dexer (D8) and shrinker (R8), and work done on the Kotlin compiler for Android use.
This session discusses how to use the Navigation Editor in Android Studio, XML or the Java API to define your navigation graph, and how that simplifies navigating around your app and handling deep linking.
Download & Feedback
Download the latest version of Android Studio 3.2 from the beta channel download page. If you are using a previous versions of Android Studio, make sure you update to Android Studio Beta 1 or higher. If you also want to maintain a stable version of Android Studio, you can run the stable release version and beta release versions of Android Studio at the same time. Learn more.
To use the mentioned Android Emulator features make sure you are running at least Android Emulator v27.3+ downloaded via the Android Studio SDK Manager.
Please note, to ensure we maintain product quality, some of the features you saw in the canary channel like Navigation Editor are not enabled by default. To turn on canary release channel features go to File → Settings → Experimental → Editor → Enable Navigation Editor.
If you find a bug or issue, feel free to file an issue. Connect with us -- the Android Studio development team ‐ on our Google+ page or on Twitter.
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!
Play Console
