The latest Android and Google Play news for app and game developers.
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!
Android's switch to LLVM/Clang as the default platform compiler in Android 7.0 opened up more possibilities for improving our defense-in-depth security posture. In the past couple of releases, we've rolled out additional compiler-based mitigations to make bugs harder to exploit and prevent certain types of bugs from becoming vulnerabilities. In Android P, we're expanding our existing compiler mitigations, which instrument runtime operations to fail safely when undefined behavior occurs. This post describes the new build system support for Control Flow Integrity and Integer Overflow Sanitization.
A key step in modern exploit chains is for an attacker to gain control of a program's control flow by corrupting function pointers or return addresses. This opens the door to code-reuse attacks where an attacker executes arbitrary portions of existing program code to achieve their goals, such as counterfeit-object-oriented and return-oriented programming. Control Flow Integrity (CFI) describes a set of mitigation technologies that confine a program's control flow to a call graph of valid targets determined at compile-time.
While we first supported LLVM's CFI implementation in select components in Android O, we're greatly expanding that support in P. This implementation focuses on preventing control flow manipulation via indirect branches, such as function pointers and virtual functions—the 'forward-edges' of a call graph. Valid branch targets are defined as function entry points for functions with the expected function signature, which drastically reduces the set of allowable destinations an attacker can call. Indirect branches are instrumented to detect runtime violations of the statically determined set of allowable targets. If a violation is detected because a branch points to an unexpected target, then the process safely aborts.
Figure 1. Assembly-level comparison of a virtual function call with and without CFI enabled.
For example, Figure 1 illustrates how a function that takes an object and calls a virtual function gets translated into assembly with and without CFI. For simplicity, this was compiled with -O0 to prevent compiler optimization. Without CFI enabled, it loads the object's vtable pointer and calls the function at the expected offset. With CFI enabled, it performs a fast-path first check to determine if the pointer falls within an expected range of addresses of compatible vtables. Failing that, execution falls through to a slow path that does a more extensive check for valid classes that are defined in other shared libraries. The slow path will abort execution if the vtable pointer points to an invalid target.
With control flow tightly restricted to a small set of legitimate targets, code-reuse attacks become harder to utilize and some memory corruption vulnerabilities become more difficult or even impossible to exploit.
In terms of performance impact, LLVM's CFI requires compiling with Link-Time Optimization (LTO). LTO preserves the LLVM bitcode representation of object files until link-time, which allows the compiler to better reason about what optimizations can be performed. Enabling LTO reduces the size of the final binary and improves performance, but increases compile time. In testing on Android, the combination of LTO and CFI results in negligible overhead to code size and performance; in a few cases both improved.
For more technical details about CFI and how other forward-control checks are handled, see the LLVM design documentation.
For Android P, CFI is enabled by default widely within the media frameworks and other security-critical components, such as NFC and Bluetooth. CFI kernel support has also been introduced into the Android common kernel when building with LLVM, providing the option to further harden the trusted computing base. This can be tested today on the HiKey reference boards.
The UndefinedBehaviorSanitizer's (UBSan) signed and unsigned integer overflow sanitization was first utilized when hardening the media stack in Android Nougat. This sanitization is designed to safely abort process execution if a signed or unsigned integer overflows by instrumenting arithmetic instructions which may overflow. The end result is the mitigation of an entire class of memory corruption and information disclosure vulnerabilities where the root cause is an integer overflow, such as the original Stagefright vulnerability.
Because of their success, we've expanded usage of these sanitizers in the media framework with each release. Improvements have been made to LLVM's integer overflow sanitizers to reduce the performance impact by using fewer instructions in ARM 32-bit and removing unnecessary checks. In testing, these improvements reduced the sanitizers' performance overhead by over 75% in Android's 32-bit libstagefright library for some codecs. Improved Android build system support, such as better diagnostics support, more sensible crashes, and globally sanitized integer overflow targets for testing have also expedited the rollout of these sanitizers.
We've prioritized enabling integer overflow sanitization in libraries where complex untrusted input is processed or where there have been security bulletin-level integer overflow vulnerabilities reported. As a result, in Android P the following libraries now benefit from this mitigation:
Moving forward, we're expanding our use of these mitigation technologies and we strongly encourage vendors to do the same with their customizations. More information about how to enable and test these options will be available soon on the Android Open Source Project.
Posted by Vishwath Mohan, Security Engineer
To keep users safe, most apps and devices have an authentication mechanism, or a way to prove that you're you. These mechanisms fall into three categories: knowledge factors, possession factors, and biometric factors. Knowledge factors ask for something you know (like a PIN or a password), possession factors ask for something you have (like a token generator or security key), and biometric factors ask for something you are (like your fingerprint, iris, or face).
Biometric authentication mechanisms are becoming increasingly popular, and it's easy to see why. They're faster than typing a password, easier than carrying around a separate security key, and they prevent one of the most common pitfalls of knowledge-factor based authentication—the risk of shoulder surfing.
As more devices incorporate biometric authentication to safeguard people's private information, we're improving biometrics-based authentication in Android P by:
Currently, biometric unlocks quantify their performance today with two metrics borrowed from machine learning (ML): False Accept Rate (FAR), and False Reject Rate (FRR).
In the case of biometrics, FAR measures how often a biometric model accidentally classifies an incorrect input as belonging to the target user—that is, how often another user is falsely recognized as the legitimate device owner. Similarly, FRR measures how often a biometric model accidentally classifies the user's biometric as incorrect—that is, how often a legitimate device owner has to retry their authentication. The first is a security concern, while the second is problematic for usability.
Both metrics do a great job of measuring the accuracy and precision of a given ML (or biometric) model when applied to random input samples. However, because neither metric accounts for an active attacker as part of the threat model, they do not provide very useful information about its resilience against attacks.
In Android 8.1, we introduced two new metrics that more explicitly account for an attacker in the threat model: Spoof Accept Rate (SAR) and Imposter Accept Rate (IAR). As their names suggest, these metrics measure how easily an attacker can bypass a biometric authentication scheme. Spoofing refers to the use of a known-good recording (e.g. replaying a voice recording or using a face or fingerprint picture), while impostor acceptance means a successful mimicking of another user's biometric (e.g. trying to sound or look like a target user).
We use the SAR/IAR metrics to categorize biometric authentication mechanisms as either strong or weak. Biometric authentication mechanisms with an SAR/IAR of 7% or lower are strong, and anything above 7% is weak. Why 7% specifically? Most fingerprint implementations have a SAR/IAR metric of about 7%, making this an appropriate standard to start with for other modalities as well. As biometric sensors and classification methods improve, this threshold can potentially be decreased in the future.
This binary classification is a slight oversimplification of the range of security that different implementations provide. However, it gives us a scalable mechanism (via the tiered authentication model) to appropriately scope the capabilities and the constraints of different biometric implementations across the ecosystem, based on the overall risk they pose.
While both strong and weak biometrics will be allowed to unlock a device, weak biometrics:
These measures are intended to allow weaker biometrics, while reducing the risk of unauthorized access.
Starting in Android P, developers can use the BiometricPrompt API to integrate biometric authentication into their apps in a device and biometric agnostic way. BiometricPrompt only exposes strong modalities, so developers can be assured of a consistent level of security across all devices their application runs on. A support library is also provided for devices running Android O and earlier, allowing applications to utilize the advantages of this API across more devices .
Here's a high-level architecture of BiometricPrompt.
The API is intended to be easy to use, allowing the platform to select an appropriate biometric to authenticate with instead of forcing app developers to implement this logic themselves. Here's an example of how a developer might use it in their app:
Biometrics have the potential to both simplify and strengthen how we authenticate our digital identity, but only if they are designed securely, measured accurately, and implemented in a privacy-preserving manner.
We want Android to get it right across all three. So we're combining secure design principles, a more attacker-aware measurement methodology, and a common, easy to use biometrics API that allows developers to integrate authentication in a simple, consistent, and safe manner.
Acknowledgements: This post was developed in joint collaboration with Jim Miller
Posted by David Brazdil and Nicolas Geoffray, Software Engineers
In Android, we care immensely about providing the best experience to our users and our developers. With each OS release, new features enable you to provide amazing experiences for users; however, we noticed that some app developers have been using non-SDK interfaces, which leads to increased crashes for users and emergency rollouts for developers. We want to do better and need your help to ensure that Android is stable with each new OS.
Three months ago, we announced our plans to start restricting the usage of non-SDK interfaces in Android P. We know these restrictions can impact your release workflow, and we want to make sure you have the tools to detect usage of non-SDK interfaces, as well as time in your planning for adjusting to the new policies and for giving us feedback.
In the Developer Preview and Beta 1, we have provided ways for you to see the impact of these restrictions on your app. In the Developer Preview, use of restricted APIs show up in logs and toast messages, and in Beta 1, we provided a StrictMode policy that allows you to programmatically find these restrictions and do your own logging. For example:
We understand there can be multiple reasons apps want to use non-SDK interfaces, and ensuring your app will continue to work in Android P is important to us. Many of you have explained your use cases through our issue tracker (thank you!), and for most of these requests, we have lifted the restrictions on specific non-SDK interfaces for Android P by adding them to the greylist. In addition, our team has conducted static analysis on millions of apps and processed thousands of automated reports from internal and external beta testers. Through this analysis, we have identified additional non-SDK interfaces that apps rely on and added them to the greylist. For everything on the greylist, we will be investigating public SDK alternatives for future releases. However, it's possible we may have missed some non-SDK interface uses, so we have made the majority of them available for apps whose target SDK is Android Oreo or below.
In summary, apps running on Android P will be subject to restricted usage of non-SDK interfaces. If you are targeting Android P, the greylist shows the non-SDK interfaces that will still be available, while all other non-SDK interfaces will not be accessible. If you are targeting Android Oreo or below, most restrictions will not apply, but you will get logcat warnings if you are accessing non-SDK interfaces that are not in the greylist (note that users don't see such warnings).
Try out our new Beta 2 release and use StrictMode to detect your non-SDK interfaces usage. You should expect Beta 2 to closely match what the final release will implement for restricting non-SDK interface usages. Also, please take a look at our new FAQ, which we hope will answer any questions you have around the feature. If not, let us know!
Posted by Hoi Lam, Lead Developer Advocate, Wear OS by Google
From the outset of the Wear OS by Google developer preview, battery life has been a major focus area. When we talked to the developer community, the update that attracted the most feedback was the disabling of alarms and jobs for background apps. After listening to developer feedback and reviewing the battery statistics, we are reversing this change. This should be reflected in all connected Wear OS preview devices, so there is no need to reflash your device.
The decision came as we reviewed the feedback and saw that a strict on/off setting prevents reasonable usage and promotes anti-patterns. Going forward, we plan to leverage the App Standby Buckets feature in Android P to fine-tune a suitable setting for Wear OS devices. The exact setting for alarms and jobs for background apps is still being iterated on. Developers are advised to follow the best practices to make sure their apps behave well, whichever bucket the apps are in.
Another area that developers should pay attention to is the strengthening of input and data privacy for background apps in Android P. Depending on an app's requirements, developers may need to use a foreground service to enable access to the device sensor throughout the day.
We expect to provide more updates to this preview before the final production release. Please submit any bugs you find via the Wear OS by Google issue tracker. The earlier you submit them, the higher the likelihood that we can include the fixes in the final release.
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!
Posted by Iliyan Malchev, Project Treble Architect
Android P Beta available at android.com/beta
As Android continues to evolve, each new release of the OS brings new features, new user experiences, and better security. It is important that these new releases find their way to mobile devices as fast as possible.
Yesterday, we announced that the following devices, in addition to Pixel and Pixel 2, now support Android P Beta: Sony Xperia XZ2, Xiaomi Mi Mix 2S, Nokia 7 Plus, Oppo R15 Pro, Vivo X21, OnePlus 6 and Essential PH‑1. Android P Beta provides an opportunity for developers and early adopters around the world to try the latest Android release, test their apps, and provide feedback.
In this post, we provide an update to Project Treble and the technology that allowed us to bring Android Beta to more phones this year.
Bringing the new Android release quickly to the hands of users takes a combined effort between Google, silicon manufacturers (SM), device manufacturers (OEMs), and carriers. This process is technically challenging and requires aligning the schedules between our industry partners.
To reduce the technical difficulties, we launched Project Treble as part of Android Oreo.
Next, to capitalize on the foundation we built, we collaborated closely with the silicon manufacturers, where the journey of making an Android device always begins.
Any device with the latest version of Android must be based on an SoC with the proper software support for it. This software, commonly referred to as the Board Support Package (BSP), contains not only the chip-specific vendor implementation, but also all of the Android Open Source Project (AOSP) and pieces of the framework that are missing from AOSP itself (e.g., carrier-specific telephony functionality).
These BSPs are the starting point for all device launches. OEMs adapt the vendor implementation to their hardware and add their own custom framework components.
While silicon manufacturers always want the latest version of Android in their BSPs, the costs have been prohibitive. By making it possible for newer AOSP frameworks to run on older, already-released vendor implementations, Project Treble dramatically reduces the need for continuous investment in older silicon to support each Android release. Silicon manufacturers have to do all this work just once, rather than every time there is a new release of Android.
However, that first time still has to happen. Below is a chart, which illustrates the effort the various actors expend over time as they go through each release. You can think of it as code churn or bug count over time.
The chart shows how there is very little time in the year for Google, silicon manufacturers, and the OEMs to all this work. Any overlap between phases causes code churn and introduces significant schedule risk. For OEMs who target the holiday season, it is often safer to launch on an older BSP with a year-old or even older Android version. This dynamic has been at the heart of the slow uptake of the latest Android release, even on flagship devices.
To solve this, we've worked closely with Qualcomm, MediaTek and Samsung Electronics’ System LSI Business to co-develop their BSPs, starting with Android P. Their BSPs are now ready for Android P on a much-accelerated schedule, reducing the overall effort significantly. These silicon manufacturers are now able to provide a stable and high-quality release much earlier than before, allowing OEMs to bring the latest innovations of Android to their customers across the globe.
This is an important step in accelerating the adoption of Android releases that bring numerous benefits to our partners, users, and Android developers. We look forward to seeing many more partners launch or upgrade devices to Android P.
Posted by Erik Kline, Android software engineer, and Ben Schwartz, Jigsaw software engineer
The first step of almost every connection on the internet is a DNS query. A client, such as a smartphone, typically uses a DNS server provided by the Wi-Fi or cellular network. The client asks this DNS server to convert a domain name, like www.google.com, into an IP address, like 2607:f8b0:4006:80e::2004. Once the client has the IP address, it can connect to its intended destination.
When the DNS protocol was designed in the 1980s, the internet was a much smaller, simpler place. For the past few years, the Internet Engineering Task Force (IETF) has worked to define a new DNS protocol that provides users with the latest protections for security and privacy. The protocol is called "DNS over TLS" (standardized as RFC 7858).
Like HTTPS, DNS over TLS uses the TLS protocol to establish a secure channel to the server. Once the secure channel is established, DNS queries and responses can't be read or modified by anyone else who might be monitoring the connection. (The secure channel only applies to DNS, so it can't protect users from other kinds of security and privacy violations.)
The Android P Developer Preview includes built-in support for DNS over TLS. We added a Private DNS mode to the Network & internet settings.
By default, devices automatically upgrade to DNS over TLS if a network's DNS server supports it. But users who don't want to use DNS over TLS can turn it off.
Users can enter a hostname if they want to use a private DNS provider. Android then sends all DNS queries over a secure channel to this server or marks the network as "No internet access" if it can't reach the server. (For testing purposes, see this community-maintained list of compatible servers.)
DNS over TLS mode automatically secures the DNS queries from all apps on the system. However, apps that perform their own DNS queries, instead of using the system's APIs, must ensure that they do not send insecure DNS queries when the system has a secure connection. Apps can get this information using a new API: LinkProperties.isPrivateDnsActive().
LinkProperties.isPrivateDnsActive()
With the Android P Developer Preview, we're proud to present built-in support for DNS over TLS. In the future, we hope that all operating systems will include secure transports for DNS, to provide better protection and privacy for all users on every new connection.
Posted by Chad Brubaker, Senior Software Engineer Android Security
Android is committed to keeping users, their devices, and their data safe. One of the ways that we keep data safe is by protecting all data that enters or leaves an Android device with Transport Layer Security (TLS) in transit. As we announced in our Android P developer preview, we're further improving these protections by preventing apps that target Android P from allowing unencrypted connections by default.
This follows a variety of changes we've made over the years to better protect Android users.To prevent accidental unencrypted connections, we introduced the android:usesCleartextTraffic manifest attribute in Android Marshmallow. In Android Nougat, we extended that attribute by creating the Network Security Config feature, which allows apps to indicate that they do not intend to send network traffic without encryption. In Android Nougat and Oreo, we still allowed cleartext connections.
android:usesCleartextTraffic
If your app uses TLS for all connections then you have nothing to do. If not, update your app to use TLS to encrypt all connections. If you still need to make cleartext connections, keep reading for some best practices.
Android considers all networks potentially hostile and so encrypting traffic should be used at all times, for all connections. Mobile devices are especially at risk because they regularly connect to many different networks, such as the Wi-Fi at a coffee shop.
All traffic should be encrypted, regardless of content, as any unencrypted connections can be used to inject content, increase attack surface for potentially vulnerable client code, or track the user. For more information, see our past blog post and Developer Summit talk.
No, it's not.
Once your server supports TLS, simply change the URLs in your app and server responses from http:// to https://. Your HTTP stack handles the TLS handshake without any more work.
If you are making sockets yourself, use an SSLSocketFactory instead of a SocketFactory. Take extra care to use the socket correctly as SSLSocket doesn't perform hostname verification. Your app needs to do its own hostname verification, preferably by calling getDefaultHostnameVerifier() with the expected hostname. Further, beware that HostnameVerifier.verify() doesn't throw an exception on error but instead returns a boolean result that you must explicitly check.
getDefaultHostnameVerifier()
HostnameVerifier.verify()
While you should use TLS for all connections, it's possibly that you need to use cleartext traffic for legacy reasons, such as connecting to some servers. To do this, change your app's network security config to allow those connections.
We've included a couple example configurations. See the network security config documentation for a bit more help.
If you need to allow connections to a specific domain or set of domains, you can use the following config as a guide:
<network-security-config> <domain-config cleartextTrafficPermitted="true"> <domain includeSubdomains="true">insecure.example.com</domain> <domain includeSubdomains="true">insecure.cdn.example.com</domain> </domain-config> </network-security-config>
If your app supports opening arbitrary content from URLs over insecure connections, you should disable cleartext connections to your own services while supporting cleartext connections to arbitrary hosts. Keep in mind that you should be cautious about the data received over insecure connections as it could have been tampered with in transit.
<network-security-config> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">example.com</domain> <domain includeSubdomains="true">cdn.example2.com</domain> </domain-config> <base-config cleartextTrafficPermitted="true" /> </network-security-config>
If your library directly creates secure/insecure connections, make sure that it honors the app's cleartext settings by checking isCleartextTrafficPermitted before opening any cleartext connection.
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
Play Console
