The latest Android and Google Play news for app and game developers.
Join us in congratulating the latest apps and games entering the Android Excellence program on Google Play. This diverse group of apps and games is recognized for their high quality, great user experience, and strong technical performance. Whether you're interested in learning meditation or a new language, or are looking for a game about butterflies or warships, we're excited to dive in to these new collections.
Check out a few of our highlighted apps.
Test your skills with these highlighted games.
See the full list of Android Excellence apps and games.
Explore other great apps and games in the Editors' Choice section on Google Play and discover best practices to help you build quality apps and games.
How useful did you find this blogpost?
★ ★ ★ ★ ★
Posted by Dave Burke, VP of Engineering
Today we're rolling out Beta 3 of Android P, our next milestone in this year's Android P developer preview. With the developer APIs already finalized in the previous update, Beta 3 now takes us very close to what you'll see in the final version of Android P, due later this summer.
Android P Beta 3 includes the latest bug fixes and optimizations for stability and polish, together with the July 2018 security updates. It's a great way to test your apps now to make sure they are ready before the final release. Give Beta 3 a try and let us know what you think!
You can get Android P Beta 3 on Pixel devices by enrolling here. If you're already enrolled and received the Android P Beta 2 on your Pixel device, you'll automatically get the update to Beta 3. Partners who are participating in the Android P Beta program will also be updating their devices to Beta 3 over the coming weeks.
Today's preview update includes the Beta 3 system images for Pixel devices and the Android Emulator, as well as an update to the Android Studio build tools to include D8 as an independent tool. Beta 3 is an early release candidate build of Android with near-final system behaviors and the official Android P APIs (API level 28).
With the Beta 3 system images and updated build tools, you've got everything you need to test your apps or extend them with Android P features like multi-camera support, display cutout, enhanced notifications, ImageDecoder, TextClassifier, and many others. In your testing, make sure to account for App standby buckets, privacy restrictions, and restrictions on non-SDK interfaces.
First, make your app compatible and give your users a seamless transition to Android P. Just install your current app from Google Play on an Android P Beta device or emulator and test -- the app should run and look great, and handle the Android P 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.
If you don't have a supported device, remember that you can instead set up an Android Virtual Device on the Android Emulator for your test environment. 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 a 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 API 28 should be a small jump. When you change your targeting, make sure your app supports all of the applicable behavior changes.
It's also important to test your apps for uses of non-SDK interfaces and reduce your reliance on them. As noted recently, Android P restricts 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 that you can use in 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.
As soon as you're ready, 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 existing users to test compatibility on their devices.
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. With beta testing you can get early feedback from a small group of users -- including Beta 3 users — and then do a staged rollout to production.
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.
Also, the Android engineering team will host a Reddit AMA on r/androiddev to answer your technical questions about Android P on July 19 from 11:30-1 PM (Pacific Time). Look out for an announcement on r/androiddev in the coming weeks. We look forward to addressing your questions!
Posted By Dave Burke, VP of Engineering
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.
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.
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.
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.
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 with conversations and smart replies [left], images and stickers [right].
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.
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. Take a look at the Android P features overview for a complete list of the new features and APIs.
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.
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.
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.
We're looking forward to seeing your apps on Android P!
Congratulations to the latest apps and games featured in the Android Excellence program on Google Play. As a reminder, these collections are refreshed every three months and recognize apps and games that set the bar for high quality, great user experience, and strong technical performance.
If you're looking for some new apps, here are a few highlights.
Here are a few of our favorite new games joining the collection.
Dashlane
Holstelworld
iCook
Keeper Password Manager
Keepsafe Photo Vault
Mobisystems OfficeSuite
PhotoGrid
Runtastic Results
Seven - 7 Minute Workout Training Challenge
SoloLearn: Learn to Code for Free
Tube Map
WPS Office
Azur Lane アズールレーン
CodyCross
Into the Dead 2
Little Panda Restaurant
MARVEL Contest of Champions
Orbital 1
Rooms of Doom
Sky Dancer Run
Sling Kong
Soul Knight
How useful did you find this blogpost? ★ ★ ★ ★ ★
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.
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.
Based in Seattle, Big Fish Games was founded in 2002. Starting as a game studio, they quickly turned into a major publisher and distributor of casual games. Leading up to the launch of their hit time management game, Cooking Craze, the team ran an open beta on Google Play.
Big Fish Games found that using open beta provided more than 10x the amount of user feedback from around the world, and also gave them access to key metrics and Android Vitals in the Play Console. The ability to monitor game performance metrics pre-launch allowed the team to focus on areas of improvement, which lead to a 21% reduction in crash rate. The larger sample size of beta testers also provided more insights on player behavior and helped achieve a +7% improvement in day 1, day 7, and day 30 retention rates.
You can also learn more pre-launch best practices and strategies to improve performance post-launch at our Google Developer Day on Monday, March 19th at GDC. Sign up to stay informed.
Kicking off the new year, we're excited to welcome our latest group of Android Excellence apps and games. These awardees represent some of the best experiences and top performing apps and games on the Play Store and can be found with other great selections on the Editors' Choice page.
If you're looking for some new apps, below are a few highlights.
Congratulations to the newly added Android Excellence apps and games.
Acorns
Airbnb
Blink Health
Blinkist
Clue
Ditty
EyeEm
Fabulous
IFTTT
iReader
Journey
KKBOX
LinkedIn
Mobills: Budget Planner
Musixmatch
Shpock
Stocard
Video Editor
ViewRanger
YAZIO
YOP
Bit Heroes
Bloons Supermonkey 2
Dancing Line
DEAD WARFARE: Zombie
Dragon Project
Fire Emblem Heroes
Futurama: Worlds of Tomorrow
Idle Heroes
Last Day on Earth: Survival
Lords Mobile
Lumino City
Modern Combat Versus
Old Man's Journey
The Walking Dead No Man's Land
War Wings
Explore other great apps and games in the Editors' Choice section on Google Play and discover best practices to help you build quality apps and games for people to love.
At Google I/O 2017, we announced a redesign of the Android TV's home screen. We expanded the recommendation row concept so that each app can have its own row (or multiple rows) of content on the home screen. Since the release of the new home screen, we have seen increased adoption of the new recommendation channels for Android Oreo in a wide variety of apps.
With more and more apps surfacing high-quality recommendations using the new channels, the legacy recommendation row in the new home screen on Android O will be phased out over the next year.
Currently, when an app creates recommendations with the legacy notification based API the content is added to a channel for that app. The channel may already exist if there was recommended content for it when you upgraded from Android N (or below). If the there is no channel for the app, it will be automatically generated for you. In either case, the user can't add or remove programs from the channel, but they can move, hide, and show the channel. When an app starts to use the new API to add its own channels, the system removes the auto-generated channel and the app takes over control of the display of their content.
Over the next year, we will phase out the automatic generation of channels. Instead of generating multiple channels, one for each app's legacy recommendations, we will insert one channel for all legacy recommendations. This channel will appear at the bottom of the channel list. Users can move or remove it. When a user upgrades to Android O, the previous recommendation row from Android N (and below) becomes a channel at the bottom of the home screen.
If you have not updated your app to post content to the new channels on the home screen, take a look at our documentation, codelab, and sample to get started.
We look forward to more and more apps taking advantage of the new changes in the home screen. We love to hear your feedback, so please visit the Android TV Developer Community on G+ to share your thoughts and ideas.
Android Oreo is stuffed full of security enhancements. Over the past few months, we've covered how we've improved the security of the Android platform and its applications: from making it safer to get apps, dropping insecure network protocols, providing more user control over identifiers, hardening the kernel, making Android easier to update, all the way to doubling the Android Security Rewards payouts. Now that Oreo is out the door, let's take a look at all the goodness inside.
Android already supports Verified Boot, which is designed to prevent devices from booting up with software that has been tampered with. In Android Oreo, we added a reference implementation for Verified Boot running with Project Treble, called Android Verified Boot 2.0 (AVB). AVB has a couple of cool features to make updates easier and more secure, such as a common footer format and rollback protection. Rollback protection is designed to prevent a device to boot if downgraded to an older OS version, which could be vulnerable to an exploit. To do this, the devices save the OS version using either special hardware or by having the Trusted Execution Environment (TEE) sign the data. Pixel 2 and Pixel 2 XL come with this protection and we recommend all device manufacturers add this feature to their new devices.
Oreo also includes the new OEM Lock Hardware Abstraction Layer (HAL) that gives device manufacturers more flexibility for how they protect whether a device is locked, unlocked, or unlockable. For example, the new Pixel phones use this HAL to pass commands to the bootloader. The bootloader analyzes these commands the next time the device boots and determines if changes to the locks, which are securely stored in Replay Protected Memory Block (RPMB), should happen. If your device is stolen, these safeguards are designed to prevent your device from being reset and to keep your data secure. This new HAL even supports moving the lock state to dedicated hardware.
Speaking of hardware, we've invested support in tamper-resistant hardware, such as the security module found in every Pixel 2 and Pixel 2 XL. This physical chip prevents many software and hardware attacks and is also resistant to physical penetration attacks. The security module prevents deriving the encryption key without the device's passcode and limits the rate of unlock attempts, which makes many attacks infeasible due to time restrictions.
While the new Pixel devices have the special security module, all new GMS devices shipping with Android Oreo are required to implement key attestation. This provides a mechanism for strongly attesting IDs such as hardware identifiers.
We added new features for enterprise-managed devices as well. In work profiles, encryption keys are now ejected from RAM when the profile is off or when your company's admin remotely locks the profile. This helps secure enterprise data at rest.
As part of Project Treble, the Android framework was re-architected to make updates easier and less costly for device manufacturers. This separation of platform and vendor-code was also designed to improve security. Following the principle of least privilege, these HALs run in their own sandbox and only have access to the drivers and permissions that are absolutely necessary.
Continuing with the media stack hardening in Android Nougat, most direct hardware access has been removed from the media frameworks in Oreo resulting in better isolation. Furthermore, we've enabled Control Flow Integrity (CFI) across all media components. Most vulnerabilities today are exploited by subverting the normal control flow of an application, instead changing them to perform arbitrary malicious activities with all the privileges of the exploited application. CFI is a robust security mechanism that disallows arbitrary changes to the original control flow graph of a compiled binary, making it significantly harder to perform such attacks.
In addition to these architecture changes and CFI, Android Oreo comes with a feast of other tasty platform security enhancements:
Android Instant Apps run in a restricted sandbox which limits permissions and capabilities such as reading the on-device app list or transmitting cleartext traffic. Although introduced during the Android Oreo release, Instant Apps supports devices running Android Lollipop and later.
In order to handle untrusted content more safely, we've isolated WebView by splitting the rendering engine into a separate process and running it within an isolated sandbox that restricts its resources. WebView also supports Safe Browsing to protect against potentially dangerous sites.
Lastly, we've made significant changes to device identifiers to give users more control, including:
net.hostname
Build.getSerial() API
Android Oreo brings in all of these improvements, and many more. As always, we appreciate feedback and welcome suggestions for how we can improve Android. Contact us at security@android.com.
_____________________________________________________________________
1: Glenn Wilkinson and team at Sensepost, UK, Célestin Matte, Mathieu Cunche: University of Lyon, INSA-Lyon, CITI Lab, Inria Privatics, Mathy Vanhoef, KU Leuven
Play Console
