Category Archives: Android Developers Blog

An Open Handset Alliance Project

Launching the Indie Games Accelerator in Asia – helping gaming startups find success on Google Play

Posted by Anuj Gulati, Developer Marketing Manager, Google Play and Sami Kizilbash, Developer Relations Program Manager, Google

Emerging markets now account for more than 40% of game installs on Google Play. Rapid smartphone adoption in these regions presents a new base of engaged gamers that are looking for high quality mobile gaming experiences. At Google Play, we are focused on helping local game developers from these markets achieve their full potential and make the most of this opportunity.

Indie Games Accelerator is a new initiative to support top indie game startups from India, Indonesia, Malaysia, Pakistan, Philippines, Singapore, Thailand and Vietnam who are looking to supercharge their growth on Android. This four month program is a special edition of Launchpad Accelerator, designed in close collaboration with Google Play, featuring a comprehensive gaming curriculum and mentorship from top mobile gaming experts.

Successful participants will be invited to attend two all-expense-paid gaming bootcamps at the Google Asia-Pacific office in Singapore, where they will receive personalized mentorship from Google teams and industry experts. Additional benefits include Google Cloud Platform credits, invites to exclusive Google and industry events, and more.

Visit the program website to find out more and apply now.

How useful did you find this blogpost?

★ ★ ★ ★ ★

Android Studio 3.2 Beta

Posted by Jamal Eason, Product Manager, Android

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:

  • Android App Bundle support - The Android App Bundle is a new publishing format that uses the Google Play's Dynamic Delivery, which delivers a smaller, optimized APK that only contains the resources needed for a specific device. Without any code changes, you can take advantage of the app size savings of an Android App Bundle by navigating to Build → Build Bundle / APK or Build → Generate Signed Bundle / APK.

Build Android App Bundle

  • Emulator Snapshots - With Android Studio 3.2 you can create snapshots at any emulator state and then start a snapshot in under 2 seconds. You can pre-configure an Android Virtual Device (AVD) snapshot with the apps, data and settings that you want and then repeatedly go back to the same snapshot. Learn more.

Android Emulator Snapshots

  • Energy Profiler - The new Energy Profiler in the performance profiler suite can help you understand the energy impact of your app on an Android device. You can now visualize the estimated energy usage of system components, plus inspect background events that may contribute to battery drain.

Energy Profiler

Check out the full write-up of all the major features organized by development flow listed below and on the canary blog:

Develop

  • Navigation Editor
  • AndroidX Refactoring
  • Sample Data
  • Material Design Update
  • Android Slices
  • CMakeList editing
  • What's New Assistant
  • New Lint Checks
  • Intellij Platform Update

Build

  • Android App Bundle
  • D8 Desugaring
  • R8 Optimizer
 Test
  • Android Emulator Snapshots
  • Screen Record in Android Emulator
  • Virtual Scene Android Emulator Camera
  • ADB Connection Assistant

Optimize

  • Energy Profiler
  • System Trace
  • Profiler Sessions
  • Automatic CPU Recording
  • JNI Reference Tracking

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:

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.

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!

Better Biometrics in Android P

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:

  • Defining a better model to measure biometric security, and using that to functionally constrain weaker authentication methods.
  • Providing a common platform-provided entry point for developers to integrate biometric authentication into their apps.

A better security model for biometrics

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).

Strong vs. Weak Biometrics

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:

  • require the user to re-enter their primary PIN, pattern, password or a strong biometric to unlock a device after a 4-hour window of inactivity, such as when left at a desk or charger. This is in addition to the 72-hour timeout that is enforced for both strong and weak biometrics.
  • are not supported by the forthcoming BiometricPrompt API, a common API for app developers to securely authenticate users on a device in a modality-agnostic way.
  • can't authenticate payments or participate in other transactions that involve a KeyStore auth-bound key.
  • must show users a warning that articulates the risks of using the biometric before it can be enabled.

These measures are intended to allow weaker biometrics, while reducing the risk of unauthorized access.

BiometricPrompt API

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:

Conclusion

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

Grow and optimize your subscriptions with new Google Play features

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.

More control for subscribers

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:

  • View all of their subscriptions to see details and status
  • Manage and update payment methods, including setting up a backup payment method
  • Renew a subscription
  • Restore a cancelled subscription
  • Cancel a subscription

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.

More control for you

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.

Better for everyone

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?

★ ★ ★ ★ ★

Google Play security metadata and offline app distribution

Posted by James Bender, Product Manager, Google Play

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.

How useful did you find this blogpost?

★ ★ ★ ★ ★

#IMakeApps – Celebrating app makers worldwide

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.

Share your story

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.

How useful did you find this blogpost?

★ ★ ★ ★ ★

An Update on non-SDK restrictions in Android P

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!

Wear OS developer preview reenabling alarms and jobs for background apps

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.

App Standby Buckets

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.

Input and data privacy in background apps

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.

Please give us your feedback

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.

Android P Beta 2 and final APIs!

Posted By Dave Burke, VP of Engineering

Android P Logo

Four weeks ago at Google I/O we released the first beta version of Android P, putting AI at the core of the operating system and focusing on intelligent and simple experiences.

We talked about some of Android's newest features in the keynotes and went deep on the developer APIs during the breakouts. If you missed the livestream, make sure to check out the full playlist of Android talks.

Today we're releasing Android P Beta 2, an update that includes the final Android P APIs, the latest system images, and updated developer tools to help you get ready for the consumer release coming later in the summer.

You can get Android P Beta 2 on Pixel devices by enrolling here. If you're already enrolled and received the Android P Beta 1 on your Pixel device, you'll automatically get the update to Beta 2. Partners that are participating in the Android P Beta program will be updating their devices over the coming weeks.

Enhance your app with Android P features and APIs

Android P Beta 2 is the latest update of our upcoming Android P platform and includes the final APIs (API level 28) as well as the official SDK. You can get started building with the Android P features and APIs today. Here are a few we want you to try -- head over to the features overview for more.

Machine learning at the core

Adaptive battery image

We partnered with DeepMind on a feature we call Adaptive Battery that uses machine learning to prioritize system resources for the apps the user cares about most. If your app is optimized for Doze, App Standby, and Background Limits, Adaptive Battery should work well for you right out of the box. Make sure to check out the details in the power documentation to see how it works and where the impacts could be, and test your apps to make sure they are ready.

App Actions is a new way to help you raise the visibility of your app and help drive engagement. Actions take advantage of machine learning on Android to surface your app to the user at just the right time, based on your app's semantic intents and the user's context. Actions work on Android P and earlier versions of the platform and they'll be available soon for you to start using. Sign up here to be notified when Actions are available.

Slices are a new way to surface rich, templated content in places like Google Search and Assistant. They're interactive, and through Android Jetpack they're compatible all the way back to KitKat. Check out the Getting Started guide to learn how to build with Slices -- you can use the SliceViewer tool to see how your Slices look. Over time we plan to expand the number of places that your Slices can appear, including remote display in other apps.

Simplicity, polish

Android P adds platform support for screens with display cutouts, and we've added new APIs to let you deliver a rich, edge-to-edge experience on the latest screens. Cutout support works seamlessly for apps, with the system managing status bar height to separate your content from the cutout. If you have immersive content, you can use the display cutout APIs to check the position and shape of the cutout and request full-screen layout around it.

All developers should check out the docs to learn how to manage the cutout area and avoid common compatibility issues that can affect apps. Make sure to test your app on a device that has a display cutout, such as one of the Android P Beta devices.

Immersive content display.

Apps with immersive content can display content fullscreen on devices with a display cutout.

If your app uses messaging notifications, take advantage of the changes in MessagingStyle that make notifications even more useful and actionable. You can now show conversations, attach photos and stickers, and even suggest smart replies. You'll soon be able to use ML Kit to generate smart reply suggestions your app.

MessagingStyle notifications MessagingStyle notifications

MessagingStyle notifications with conversations and smart replies [left], images and stickers [right].

Security

Verify purchase icon

With a range of biometric sensors in use for authentication, we've made the experience more consistent across sensor types and apps. Android P introduces a system-managed dialog to prompt the user for any supported type of biometric authentication. Apps no longer need to build their own dialog -- instead they use the BiometricPrompt API to show the standard system dialog. In addition to Fingerprint (including in-display sensors), the API supports Face and Iris authentication.

If your app is drawing its own fingerprint auth dialogs, you should switch to using the BiometricPrompt API as soon as possible.

More

If your app uses the device camera, try the new multi-camera APIs that let you access streams simultaneously from two or more physical cameras. On devices with dual cameras, you can create innovative features not possible with a single camera -- such as seamless zoom, bokeh, and stereo vision. You can get started today using any of the Android P Beta devices that offers a dual camera.

Audio apps can use the Dynamics Processing API for access to a multi-stage, multi-band dynamics processing effect to modify the audio coming out of Android devices and optimize it according to the preferences of the listener or the ambient conditions. Dynamics Processing API Take a look at the Android P features overview for a complete list of the new features and APIs.

Get started in a few simple steps

Android Virtual Device

First, make your app compatible and give your users a seamless transition to Android P. Just install your current app from Google Play on a Android P Beta device or emulator and test -- the app should run and look great, and handle Android P behavior change for all apps properly. After you've made any necessary updates, we recommend publishing to Google Play right away without changing the app's platform targeting.

If you don't have a supported device, remember that you can set up an Android Virtual Device on the Android Emulator as your test environment instead. If you haven't tried the emulator recently, you'll find that it's incredibly fast, boots in under 6 seconds, and even lets you model next-gen screens -- such as long screens and screens with display cutout.

Next, update your app's targetSdkVersion to 28 as soon as possible, so Android P users of your app can benefit from the platform's latest security, performance, and stability features. If your app is already targeting API 26+ in line with Google Play's upcoming policies, then changing to target 28 should be a small jump.

It's also important to test your apps for uses of non-SDK interfaces and reduce your reliance on them. As noted previously, in Android P we're starting a gradual process to restrict access to selected non-SDK interfaces. Watch for logcat warnings that highlight direct uses of restricted non-SDK interfaces and try the new StrictMode method detectNonSdkApiUsage() to catch accesses programmatically. Where possible, you should move to using public equivalents from the Android SDK or NDK. If there's no public API that meets your use-case, please let us know.

When you're ready, dive into Android P and learn about the new features and APIs to extend your apps. To build with the new APIs, just download the official API 28 SDK and tools into Android Studio 3.1, or use the latest version of Android Studio 3.2. Then update your project's compileSdkVersion and targetSdkVersion to API 28.

Visit the Developer Preview site for details and documentation. Also check out this video and the Google I/O Android playlist for more on what's new in Android P for developers.

Publish to Google Play alpha, beta, or production channels

Starting today you can publish your APK updates that are compiled against, or optionally targeting, API 28. Publishing an update to Google Play during the preview lets you push updates to users to test compatibility on existing devices, including devices running Android P Beta 2.

To make sure that your updated app runs well on Android P as well as older versions, a common strategy is to use Google Play's beta testing feature to get early feedback from a small group of users -- including Android P Beta 2 users — and then do a staged rollout to production.

How to get Android P Beta 2

For Pixel devices, you can enroll your device in the Android Beta program and you'll automatically receive the update to Android P Beta 2 over-the-air. If you're already enrolled and received Beta 1, watch for the update coming your way soon. Partners that are participating in the Android P Beta program will be updating their devices over the coming weeks.

You can see the full list of supported partner and Pixel devices at android.com/beta. For each device you'll find specs and links to the manufacturer's dedicated site for downloads, support, and to report issues.

Thanks for all of your feedback so far. Please continue to share feedback or requests as we work towards the consumer release later this summer. Feel free to use our hotlists for platform issues, app compatibility issues, and third-party SDK issues.

We're looking forward to seeing your apps on Android P!