Today we launched the Wear OS by Google developer preview and brought Android P platform features to wearables. The developer preview includes updated system images on the official Android Emulator and a downloadable system image for the Huawei Watch 2 Bluetooth or Huawei Watch 2 Classic Bluetooth. This initial release is intended for developers only and is not for daily or consumer use. Therefore, it is only available via manual download and flash. Please refer to the release notes for known issues before downloading and flashing your device.
In this release, we would like to highlight the following features that developers should pay attention to:
We expect to provide several 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.
We are excited to announce that Android Studio 3.1 is now available to download in the stable release channel. The focus areas for this release are around product quality and app development productivity. In addition to many underlying quality changes, we added several new features into Android Studio 3.1 that you should integrate into your development flow.
New to Android Studio 3.1 is a C++ performance profiler to help troubleshoot performance bottlenecks in your app code. For those of you with a Room or SQLite database in their your app, we added better code editor support to aid in your SQL table and query creation statements. We also added better lint support for your Kotlin code, and accelerated your testing with an updated Android Emulator with Quick Boot. If any of these features sound exciting or you are looking for the next stable version of Android Studio, you should download Android Studio 3.1 today!
Check out the list of new features in Android Studio 3.1 below, organized by key developer flows.
What's new in Android Studio 3.1
gradlew lint
Kotlin Lint checks via command line
Room Database code completion
android.enableD8
true
New Build Output Window
Quick Boot On Demand Setting
Window frameless mode in the Android Emulator
C++ CPU Profiler
Network Profiler with thread support
To recap, Android Studio 3.1 includes these new major features:
Develop
Build
Test & Debug
Optimize
Check out the release notes for more details.
Download
If you are using a previous version of Android Studio, you can upgrade to Android Studio 3.1 today or you can download the update from the official Android Studio download page.
We appreciate any feedback on things you like, issues or features you would like to see. 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.
Phones are our most personal devices we bring with us everywhere, but until now it's been hard for apps to adjust their experience to a user's continually changing environment and activity. We've heard from developer after developer that they're spending valuable engineering time to combine various signals like location and sensor data just to determine when the user has started or ended an activity like walking or driving. Even worse, when apps are independently and continuously checking for changes in user activity, battery life suffers. That's why today, we're excited to make the Activity Recognition Transition API available to all Android developers - a simple API that does all the processing for you and just tells you what you actually care about: when a user's activity has changed.
Since November of last year, the Transition API has been working behind the scenes to power the Driving Do-Not-Disturb feature launched on the Pixel 2. While it might seem simple to turn on Do-Not-Disturb when car motion is detected by the phone's sensors, many tricky challenges arise in practice. How can you tell if stillness means the user parked their car and ended a drive or simply stopped at a traffic light and will continue on? Should you trust a spike in a non-driving activity or is it a momentary classification error? With the Transition API, all Android developers can now leverage the same sets of training data and algorithmic filtering used by Google to confidently detect these changes in user activity.
Intuit partnered with us to test the Transition API and found it an ideal solution for their QuickBooks Self-Employed app:
"QuickBooks Self-Employed helps self-employed workers maximize their deductions at tax time by importing transactions and automatically tracking car mileage. Before the Transition API, we created our own solution to track mileage that combined GPS, phone sensors, and other metadata, but due to the wide variability in Android devices, our algorithm wasn't 100% accurate and some users reported missing or incomplete trips. We were able to build a proof-of-concept using the Transition API in a matter of days and it has now replaced our existing solution, offering a more reliable solution that also reduced our battery consumption. The Transition API frees us up to focus our efforts on being the best possible tax solution," say Pranay Airan and Mithun Mahadevan from Intuit.
Automatic mileage tracking in QuickBooks Self-Employed
Life360 similarly implemented the Transition API in their app with significant improvements in activity detection latency and battery consumption:
"With over 10 million active families, Life360 is the world's largest mobile app for families. Our mission is to become the must-have Family Membership that gives families peace of mind anytime and anywhere. Today we do that through location sharing and 24/7 safety features like monitoring driving behavior of family members, so measuring activities accurately and with minimal battery drain is critical. To determine when a user has started or finished a drive, our app previously relied on a combination of geofences, the Fused Location Provider API and the Activity Recognition API, but there were many challenges with that approach including how to quickly detect the start of the drive without excessively draining battery and interpreting the granular and rapidly changing reading from the raw Activity Recognition API. But in testing the Transition API, we are seeing higher accuracy and reduced battery drain over our previous solution, more than meeting our needs," says Dylan Keil from Life360.
Live location sharing in Life360
In the coming months, we will continue adding new activities to the Transition API to support even more kinds of context-aware features on Android like differentiating between road and rail vehicles. If you're ready to use the Transition API in your app, check out our API guide.
We've been working hard to make Google Play the premier platform for game discovery and a place for you to grow your business. In the last year, the number of Android users who installed a game has more than doubled. Nearly 40% of that growth came from emerging markets, including Brazil, India, Indonesia and Mexico. Our investments extend beyond the Play Store and include many key Google products:
Today, during our annual Google Developer Day at the Game Developers Conference, we introduced new tools and platforms to improve the overall game discovery on Google Play and give you more ways to deliver engaging player experiences.
With all the great games available on Google Play, we want to make discovery easier and remove friction during the install process. Installing and opening a game takes time and results in many players never getting to experience your game. We're thrilled to announce that instant apps is now available for games.
This means that with a tap, players can try a game without having to download it first. Games available instantly today include: Clash Royale, Words with Friends 2, and Bubble Witch 3 Saga, and other titles from Playtika, MZ, Jam City, and Hothead Games.
We're calling this new experience Google Play Instant. To try it out, simply launch the Google Play Store on your Android device and visit the Instant Gameplay collection. Or, you can visit the "Arcade" in our redesigned Google Play Games app and launch any of the "Instant Gameplay" collection games. Google Play Instant makes it easier to have your players invite their friends to try out games right away through social invites and lets you share games through marketing campaigns.
Google Play Instant is still in closed beta and we look forward to opening it more broadly later this year. It provides a collection of extensions to the instant apps framework that better support the needs of game developers; including a higher APK size limit to 10MB, progressive download support for executable code and game assets, and support for NDK and game engines using existing tool chains. We're also working with popular game development platform Unity, and others including Cocos, to add IDE support making it easy for developers to build instant apps. Developers can sign up for more information about Google Play Instant as it becomes available.
Discover insights from game developers who have successfully benefited from Google Play Instant. Read how Zynga, King, Hothead Games, Jam City, Playtika, MZ and Magma Mobile successfully used instant apps to acquire new users, improve retention, and effectively cross-promote their games.
We also added some useful tools to the Play Console to help you build great games, including:
This is just the start of what we have planned for 2018. We can't wait to see Google Play Instant bring new audiences to your games.
Our team's goal is simple: secure more than two billion Android devices. It's our entire focus, and we're constantly working to improve our protections to keep users safe.
Today, we're releasing our fourth annual Android security year in review. We compile these reports to help educate the public about the many different layers of Android security, and also to hold ourselves accountable so that anyone can track our security work over time.
We saw some really positive momentum last year and this post includes some, but not nearly all, of the major moments from 2017. To dive into all the details, you can read the full report at: g.co/AndroidSecurityReport2017
In May, we announced Google Play Protect, a new home for the suite of Android security services on nearly two billion devices. While many of Play Protect's features had been securing Android devices for years, we wanted to make these more visible to help assure people that our security protections are constantly working to keep them safe.
Play Protect's core objective is to shield users from Potentially Harmful Apps, or PHAs. Every day, it automatically reviews more than 50 billion apps, other potential sources of PHAs, and devices themselves and takes action when it finds any.
Play Protect uses a variety of different tactics to keep users and their data safe, but the impact of machine learning is already quite significant: 60.3% of all Potentially Harmful Apps were detected via machine learning, and we expect this to increase in the future.
Play Protect automatically checks Android devices for PHAs at least once every day, and users can conduct an additional review at any time for some extra peace of mind. These automatic reviews enabled us to remove nearly 39 million PHAs last year.
We also update Play Protect to respond to trends that we detect across the ecosystem. For instance, we recognized that nearly 35% of new PHA installations were occurring when a device was offline or had lost network connectivity. As a result, in October 2017, we enabled offline scanning in Play Protect, and have since prevented 10 million more PHA installs.
Devices that downloaded apps exclusively from Google Play were nine times less likely to get a PHA than devices that downloaded apps from other sources. And these security protections continue to improve, partially because of Play Protect's increased visibility into newly submitted apps to Play. It reviewed 65% more Play apps compared to 2016.
Play Protect also doesn't just secure Google Play—it helps protect the broader Android ecosystem as well. Thanks in large part to Play Protect, the installation rates of PHAs from outside of Google Play dropped by more than 60%.
While Google Play Protect is a great shield against harmful PHAs, we also partner with device manufacturers to make sure that the version of Android running on user devices is up-to-date and secure.
Throughout the year, we worked to improve the process for releasing security updates, and 30% more devices received security patches than in 2016. Furthermore, no critical security vulnerabilities affecting the Android platform were publicly disclosed without an update or mitigation available for Android devices. This was possible due to the Android Security Rewards Program, enhanced collaboration with the security researcher community, coordination with industry partners, and built-in security features of the Android platform.
We introduced a slew of new security features in Android Oreo: making it safer to get apps, dropping insecure network protocols, providing more user control over identifiers, hardening the kernel, and more.
We highlighted many of these over the course of the year, but some may have flown under the radar. For example, we updated the overlay API so that apps can no longer block the entire screen and prevent you from dismissing them, a common tactic employed by ransomware.
We've long said it, but it remains truer than ever: Android's openness helps strengthen our security protections. For years, the Android ecosystem has benefitted from researchers' findings, and 2017 was no different.
We continued to see great momentum with our Android Security Rewards program: we paid researchers $1.28 million, totalling more than two million dollars since the start of the program. We also increased our top-line payouts for exploits that compromise TrustZone or Verified Boot from $50,000 to $200,000, and remote kernel exploits from $30,000 to $150,000.
In parallel, we also introduced Google Play Security Rewards program and offered a bonus bounty to developers that discover and disclose select critical vulnerabilities in apps hosted on Play to their developers.
Our teams also participated in external vulnerability discovery and disclosure competitions, such as Mobile Pwn2Own. At the 2017 Mobile Pwn2Own competition, no exploits successfully compromised the Google Pixel. And of the exploits demonstrated against devices running Android, none could be reproduced on a device running unmodified Android source code from the Android Open Source Project (AOSP).
We're pleased to see the positive momentum behind Android security, and we'll continue our work to improve our protections this year, and beyond. We will never stop our work to ensure the security of Android users.
We hope you're enjoying the first developer preview of Android P. We wanted to specifically call out some backward-incompatible changes we plan to make to the cryptographic capabilities in Android P, which you can see in the developer preview.
Starting in Android P, we plan to deprecate some functionality from the BC provider that's duplicated by the AndroidOpenSSL (also known as Conscrypt) provider. This will only affect applications that specify the BC provider explicitly when calling getInstance() methods. To be clear, we aren't doing this because we are concerned about the security of the implementations from the BC provider, rather because having duplicated functionality imposes additional costs and risks while not providing much benefit.
getInstance()
If you don't specify a provider in your getInstance() calls, no changes are required.
If you specify the provider by name or by instance—for example, Cipher.getInstance("AES/CBC/PKCS7PADDING", "BC") or Cipher.getInstance("AES/CBC/PKCS7PADDING", Security.getProvider("BC"))—the behavior you get in Android P will depend on what API level your application targets. For apps targeting an API level before P, the call will return the BC implementation and log a warning in the application log. For apps targeting Android P or later, the call will throw NoSuchAlgorithmException.
Cipher.getInstance("AES/CBC/PKCS7PADDING", "BC")
Cipher.getInstance("AES/CBC/PKCS7PADDING", Security.getProvider("BC"))
NoSuchAlgorithmException
To resolve this, you should stop specifying a provider and use the default implementation.
In a later Android release, we plan to remove the deprecated functionality from the BC provider entirely. Once removed, any call that requests that functionality from the BC provider (whether by name or instance) will throw NoSuchAlgorithmException.
In a previous post, we announced that the Crypto provider was deprecated beginning in Android Nougat. Since then, any request for the Crypto provider by an application targeting API 23 (Marshmallow) or before would succeed, but requests by applications targeting API 24 (Nougat) or later would fail. In Android P, we plan to remove the Crypto provider entirely. Once removed, any call to SecureRandom.getInstance("SHA1PRNG", "Crypto") will throw NoSuchProviderException. Please ensure your apps have been updated.
SecureRandom.getInstance("SHA1PRNG", "Crypto")
NoSuchProviderException
Last week at Mobile World Congress we saw that Android's ecosystem of developers, device makers, and silicon partners continues to bring amazing experiences to users worldwide.
Looking ahead, today we're sharing the first developer preview of Android P, the newest version of Android. It's an early baseline build for developers only -- you're our most trusted reviewers and testers ;-) Early feedback from our developer community is crucial in helping us evolve the platform to meet your needs. We'd love to get you started exercising the new features and APIs in P, and as always, we depend on your early feedback and ideas, so please give us your input!
This first developer preview of Android P is just the start - we'll have lots more to share at Google I/O in May, stay tuned!
Here's a look at some of the cool features in this first preview of Android P that we want you to try and give feedback on.
Accurate indoor positioning has been a long-standing challenge that opens new opportunities for location-based services. Android P adds platform support for the IEEE 802.11mc WiFi protocol -- also known as WiFi Round-Trip-Time (RTT) -- to let you take advantage of indoor positioning in your apps.
On Android P devices with hardware support, location permission, and location enabled, your apps can use RTT APIs to measure the distance to nearby WiFi Access Points (APs). The device doesn't need to connect to the APs to use RTT, and to maintain privacy, only the phone is able to determine the distance, not the APs.
Knowing the distance to 3 or more APs, you can calculate the device position with an accuracy of 1 to 2 meters. With this accuracy, you can build new experiences like in-building navigation; fine-grained location-based services such as disambiguated voice control (e.g.,'Turn on this light'); and location-based information (e.g., 'Are there special offers for this product?').
Now apps can take full advantage of the latest device screens with fullscreen content. We've added display cutout into the platform, along with APIs that you can use to manage how your content is displayed.
Cutout support works seamlessly for apps, with the system managing status bar height to separate your content from the cutout. If you have critical, immersive content, you can also use new APIs to check the cutout shape and request full-screen layout around it. You can check whether the current device has a cutout by calling getDisplayCutout(), and then determine the location and shape of the cutout area using DisplayCutout. A new window layout attribute, layoutInDisplayCutoutMode, lets you tell the system how and when lay out your content relative to the cutout area. Details are here.
To make it easier to build and test cutout support in your app, we've added a Developer Option that simulates a cutout on any device. We recommend testing your existing apps with display cutout enabled to ensure that your content displays properly.
Apps with immersive content can display content fullscreen on devices with a display cutout.
In Android P we've put a priority on improving visibility and function in notifications. Try the new MessagingStyle notification style -- it highlights who is messaging and how you can reply. You can show conversations, attach photos and stickers, and even suggest smart replies. See the details here.
In MessagingStyle notifications you can now show conversations and smart replies [left] and even attach images and stickers [right].
You can now access streams simultaneously from two or more physical cameras on devices running Android P. On devices with either dual-front or dual-back cameras, you can create innovative features not possible with just a single camera, such as seamless zoom, bokeh, and stereo vision. The API also lets you call a logical or fused camera stream that automatically switches between two or more cameras. We're looking forward to seeing your new and exciting creations as Android P devices supporting multiple cameras reach the market in the year ahead.
Other improvements in camera include new Session parameters that help to reduce delays during initial capture, and Surface sharing that lets camera clients handle various use-cases without the need to stop and start camera streaming. We've also added APIs for display-based flash support and access to OIS timestamps for app-level image stabilization and special effects.
Android P gives you an easier way to decode images to bitmaps or drawables -- ImageDecoder, which deprecates BitmapFactory. ImageDecoder lets you create a bitmap or drawable from a byte buffer, file, or URI. It offers several advantages over BitmapFactory, including support for exact scaling, single-step decoding to hardware memory, support for post-processing in decode, and decoding of animated images.
You can decode and scale to an exact size just by calling setResize() with the target dimensions. You can also call getSampledSize() to get the image dimensions at a specific sample rate, then scale to those dimensions. If you want post-process an image -- such as applying rounded corners for circle masks or more complicated effects -- you can pass ImageDecoder any android.graphics.PostProcessor. You can also create Drawables directly, with ImageDecoder.decodeDrawable(). If the encoded image is an animated GIF or WebP, the Drawable will be an instance of the new AnimatedImageDrawable.
Android P adds built-in support for HDR VP9 Profile 2, so you can now deliver HDR-enabled movies to your users from YouTube, Play Movies, and other sources on HDR-capable devices.
We're excited to add HEIF (heic) image encoding to the platform. HEIF is a popular format for photos that improves compression to save on storage and network data. With platform support on Android P devices, it's easy to send and utilize HEIF images from your backend server. Once you've made sure that your app is compatible with this data format for sharing and display, give HEIF a try as an image storage format in your app. You can do a jpeg-to-heic conversion using ImageDecoder or BitmapFactory to obtain a bitmap from jpeg, and you can use HeifWriter in the new Support Library alpha to write HEIF still images from YUV byte buffer, Surface, or Bitmap.
We're also in the process of enhancing and refactoring the media APIs to make them easier to develop and integrate with -- watch for details coming later this year.
JobScheduler is Android's central service to help you manage scheduled tasks or work across Doze, App Standby, and Background Limits changes. In Android P, JobScheduler handles network-related jobs better for the user, coordinating with network status signals provided separately by carriers.
Jobs can now declare their estimated data size, signal prefetching, and specify detailed network requirements—carriers can report networks as being congested or unmetered. JobScheduler then manages work according to the network status. For example, when a network is congested, JobScheduler might defer large network requests. When unmetered, it can run prefetch jobs to improve the user experience, such as by prefetching headlines.
When you are adding jobs, try using setEstimatedNetworkBytes(), setIsPrefetch() and setRequiredNetwork() to let JobScheduler handle the work properly. When your job executes, be sure to use the Network object returned by JobParameters.getNetwork(), otherwise you'll implicitly use the device's default network which may not meet your requirements, causing unintended data usage.
We introduced the Neural Networks API in Android 8.1 to accelerate on-device machine learning on Android. In Android P we're expanding and improving this API, adding support for nine new ops -- Pad, BatchToSpaceND, SpaceToBatchND, Transpose, Strided Slice, Mean, Div, Sub, and Squeeze. If you have a Pixel 2 device, the DP1 build now includes an Qualcomm Hexagon HVX driver with acceleration for quantized models.
In Android P we're continuing to improve the Autofill Framework based on feedback from users and developers. Along with key bugfixes, this release includes new APIs that allow password managers to improve the Autofill user experience, such as better dataset filtering, input sanitization, and compatibility mode. Compatibility mode in particular has a high impact on end users because it lets password managers take the accessibility-based approach in apps that don't yet have full Autofill support, but without impacts on performance or security. See all the details on what's new here.
Android P adds an implementation of the GlobalPlatform Open Mobile API to Android. On supported devices, apps can use the OMAPI API to access secure elements (SE) to enable smart-card payments and other secure services. A hardware abstraction layer (HAL) provides the underlying API for enumerating a variety of Secure Elements (eSE, UICC, and others) available.
In Android P we're continuing our long-term investment to make Android the best platform for developers.
In Android P we're moving to a more consistent UI for fingerprint authentication across apps and devices. Android now provides a standard system dialog to prompt the user to touch the fingerprint sensor, managing text and placement as appropriate for the device. Apps can trigger the system fingerprint dialog using a new FingerprintDialog API. We recommend switching to the new system dialog as soon as possible.
As part of a larger effort to move all network traffic away from cleartext (unencrypted HTTP) to TLS, we're also changing the defaults for Network Security Configuration to block all cleartext traffic. You'll now need to make connections over TLS, unless you explicitly opt-in to cleartext for specific domains.
To better ensure privacy, Android P restricts access to mic, camera, and all SensorManager sensors from apps that are idle. While your app's UID is idle, the mic reports empty audio and sensors stop reporting events. Cameras used by your app are disconnected and will generate an error if the app tries to use them. In most cases, these restrictions should not introduce new issues for existing apps, but we recommend removing these requests from your apps.
We will also enable encryption of Android backups with a client-side secret. This feature is still in active development and will be launched in a future Android P preview release.
Longer term we're working to bring support for per-network randomization of associated MAC addresses to the platform. On supported devices running Android P, you can enable this experimentally for testing as a new developer option.
Android P also gives the user control over access to the platform's build.serial identifier by putting it behind the READ_PHONE_STATE permission. Direct access to this identifier has been deprecated since Android 8.0. In order to access the build.serial identifier, you should use the Build.getSerial() method.
Build.getSerial()
We're working to bring performance and efficiency improvements to all apps through the ART runtime. We've expanded ART's use of execution profiles to optimize apps and reduce in-memory footprint of compiled app code. ART now uses profile information for on-device rewriting of DEX files, with reductions up to 11% across a range of popular apps. We expect these to correlate closely with reductions in system DEX memory usage and faster startup times for your apps.
Kotlin is a first-class language on Android, and if you haven't tried it yet, you should! We've made an enduring commitment to Kotlin in Android and continue to expand support including optimizing the performance of Kotlin code. In P you'll see the first results of this work -- we've improved several compiler optimizations, especially those that target loops, to extract better performance. We're also continuing to work in partnership with JetBrains to optimize Kotlin's generated code. You can get all of the latest Kotlin performance improvements just by keeping Android Studio's Kotlin plugin up-to-date.
In Android P we continue to refine Doze, App Standby, and Background Limits to further improve battery life; please be sure to try your apps with these and send feedback.
Android P is shaped by our longer-term initiatives to modernize the foundations of Android and the apps that run on it. As we announced recently, Google Play will require all app updates to target Android Oreo (targetSdkVersion 26 or higher) by November 2018, with support for 64-bit hardware on the horizon for 2019.
In line with these changes, Android P will warn users with a dialog when they install an app that targets a platform earlier than Android 4.2 (targetSdkVersion less than 17), and future platform versions will continue to increment that lower bound. We're encouraging every Android developer to start planning the migration to target API 26 now, and to start the migration work as soon as possible. Here's a checklist of resources for help and support -- we're looking forward to seeing your apps getting the most from modern Android.
A key issue for users and developers is app compatibility -- making sure that apps are ready for new platform versions as they arrive, without risk of crashes for users and emergency rollouts for developers. Apps that use Android's public APIs from the SDK or NDK are in a good position to be compatible, but apps that use private Android interfaces and libraries are not.
So with Android P we're starting a gradual process to restrict access to selected non-SDK interfaces, asking developers -- including app teams inside Google -- to use the public equivalents instead. In cases where there is no public equivalent for your use-case, please let us know -- we want to make sure that this process is as smooth as possible for developers, so we'll use your feedback to ensure the initial rollout only affects APIs where developers can easily migrate to public alternatives. More about the restrictions is here.
First, make your app compatible to give your users a seamless transition to Android P. Just download a device system image or emulator system image, install your current app, and test -- the app should run and look great, and handle behavior changes properly. After you've made any necessary updates, we recommend publishing to Google Play right away without changing the app's platform targeting.
Remember, you don't need a supported Pixel device to test or develop on Android P. For most uses we highly recommend setting up an Android Virtual Device on the Android Emulator as a test environment instead. If you haven't tried the emulator recently, you'll find that it's incredibly fast , boots in under 6 seconds, convenient to use, and you can even model next-gen screens -- such as long screens and screens with camera cutout.
Next, change your app's targeting to "P" and run it with the full Android P experience. Set your app's targetSdkVersion to 'P' and compileSdkVersion to android-P, build, and test. Make sure to read the behavior changes for apps targeting P to find areas you will want to test and might need to adjust.
When you're ready, dive into Android P and learn about the many new features and APIs you can take advantage of in your app. To make it easier to explore the new APIs, take a look at the API diff report, along with the Android P API reference. Visit the P Developer Preview site for details on the preview timeline and support resources. Also check out this video highlighting what's new in Android P for developers.
To get started building with Android P, download the P Developer Preview SDK and tools into Android Studio 3.1 or use the latest Android Studio 3.2 canary version. We're also releasing an alpha version of the 28.0.0 support library for you to try.
The Android P Developer Preview includes an updated SDK with system images for testing on the official Android Emulator and on Pixel, Pixel XL Pixel 2, and Pixel 2 XL devices.
We plan to update the preview system images and SDK regularly throughout the preview. This initial release is for developers only and not intended for daily or consumer use, so we're making it available by manual download and flash only. Downloads and instructions are here.
As we get closer to a final product, we'll be inviting consumers to try it out as well, and we'll open up enrollments through Android Beta at that time. Stay tuned for details, but for now please note that Android Beta is not currently available for Android P.
As always, your feedback is critical, so please let us know what you think — the sooner we hear from you, the more of your feedback we can integrate. When you find issues, please report them here. We have separate hotlists for filing platform issues, app compatibility issues, and third-party SDK issues.
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:
New features are also available in the Android Things Console to enhance product management from prototype to production:
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.
UpdateManager
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:
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.
BluetoothConnectionManager
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%.
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!
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
