The latest Android and Google Play news for app and game developers.
Posted by James Lau, Product Manager (@jmslau)
When using the Java programming language, one of the most common pitfalls is trying to access a member of a null reference, causing a NullPointerException to be thrown. Kotlin offers protection against this by baking nullable and non-nullable types into the type system. This helps eliminate NullPointerExceptions from your code and improve your app's overall quality. When Kotlin code is calling into APIs written in the Java programming language, it relies on nullability annotations in those APIs to determine the nullability of each parameter and the return type. Unannotated parameters and return types are treated as platform types, which weakens the null-safety guarantee of Kotlin.
NullPointerException
As part of yesterday's Android 9 announcement, we have also released a new Android SDK that contains nullability annotations for some of the most frequently used APIs. This will preserve the null-safety guarantee when your Kotlin code is calling into any annotated APIs in the SDK. Even if you are using the Java programming language, you can still benefit from these annotations by using Android Studio to catch nullability contract violations.
Normally, nullability contract violations in Kotlin result in compilation errors. But to ensure the newly annotated APIs are compatible with your existing code, we are using an internal mechanism provided by the Kotlin compiler team to mark the APIs as recently annotated. Recently annotated APIs will result only in warnings instead of errors from the Kotlin compiler. You will need to use Kotlin 1.2.60 or later.
Our plan is to have newly added nullability annotations produce warnings only, and increase the severity level to errors starting in the following year's Android SDK. The goal is to provide you with sufficient time to update your code.
To get started, go to Tools > SDK Manager in Android Studio. Select Android SDK on the left menu, and make sure the SDK Platforms tab is open.
Use SDK Manager in Android Studio to install SDK for API Level 28 Revision 6
Check Android 8.+ (P) and click OK. This will install the Android SDK Platform 28 revision 6 if it is not already installed. After that, set your project's compile SDK version to API 28 to start using the new Android Pie SDK with nullability annotations.
Use the Project Structure Dialog to change your project's Compile Sdk Version to API 28
You may also need to update your Kotlin plugin in Android Studio if it's not already up-to-date. Make sure your Kotlin plugin version is 1.2.60 or later by going to Tools > Kotlin > Configure Kotlin Plugin Updates.
Once it's set up, your builds will start showing warnings if you have any code that violates nullability contracts in the Android SDK. An example of such a warning is shown below.
Sample warning from the Kotlin compiler when code violates a recently added nullability contract in the Android SDK.
You will also start seeing warnings in Android Studio's code editor if you call an Android API with the incorrect nullability. An example is shown below.
Android Studio warning about passing a null reference to a parameter annotated as a recently non-null type in the android.graphics.Path API.
You can benefit from the new nullability annotations even if your code is in the Java programming language. By default, Android Studio will highlight any nullability contract violations with a warning, like the one below:
Android Studio showing a warning about nullability contract violation in code written in the Java programming language
To ensure that you have this inspection enabled, you can go to the IDE's settings page and search for "Constant conditions & exceptions" inspection and make sure that item is checked.
Use the Inspections page under Settings to ensure the Constant conditions & exceptions code inspection is enabled.
If you are using the Java programming language, nullability contract violations will not produce any compiler warning or error. Only the in-IDE code inspections are available to flag these issues.
You can also run code inspections across your entire project and see the aggregated results. Click on Analyze > Inspect Code… to start.
The Android SDK API surface is very large, and we have only annotated a small percentage of the APIs so far - there is still lots of work remaining. Over the next several Android SDK releases, we will continue to add nullability annotations to the existing Android APIs, as well as making sure new APIs are annotated.
With the "Kotlin-friendly" Android SDK, the nullability annotations in AndroidX (part of the Jetpack family), and Android KTX, we are continuing to improve the Android APIs for developers using Kotlin. If you have not yet tried Kotlin, we encourage you to try it. Not only can Kotlin make your code more concise, it can also improve the stability of your apps.
Happy Kotlin-ing!
Posted By Megan Potoski, Product Manager, Android System UI
Smartphones are quickly moving towards smaller bezels and larger aspect ratios. On these devices, display cutouts are a popular way to achieve an edge-to-edge experience while providing space for important sensors on the front of the device. There are currently 16 cutout devices from 11 OEMs already released, including several Android P beta devices, with more on the way.
These striking displays present a great opportunity for you to showcase your app. They also mean it's more important than ever to make sure your app provides a consistently great experience across devices with one or two display cutouts, as well as devices with 18:9 and larger aspect ratios.
Examples of cutout devices: Essential PH-1 (left) and Huawei P20 (right).
With many popular and upcoming devices featuring display cutouts, what can you do to make sure your app is cutout-ready?
The good news is, for the most part your app should work as intended even on a cutout device. By default, in portrait mode with no special flags set, the status bar will be resized to be at least as tall as the cutout and your content will display in the window below. In landscape or fullscreen mode, your app window will be letterboxed so that none of your content is displayed in the cutout area.
However, there are a few areas where your app could have issues on cutout devices.
Here are a few guidelines describing what issues to look out for and how to fix them.
Rendering your app content in the cutout area can be a great way to provide a more immersive, edge-to-edge experience for users, especially for content like videos, photos, maps, and games.
An example of an app that has requested layout in the display cutout.
In Android P we added APIs to let you manage how your app uses the display cutout area, as well as to check for the presence of cutouts and get their positions.
You can use layoutInDisplayCutoutMode, a new window layout mode, to control how your content is displayed relative to the cutout. By default, the app's window is allowed to extend into the cutout area if the cutout is fully contained within a system bar. Otherwise, the window is laid out such that it does not overlap with the cutout. You can also set layoutInDisplayCutoutMode to always or never render into the cutout. Using SHORT_EDGES mode to always render into the cutout is a great option if you want to take advantage of the full display and don't mind if a bit of content gets obscured by the cutout.
If you are rendering into the cutout, you can use getDisplayCutout() to retrieve a DisplayCutout that has the cutout's safe insets and bounding box(es). These let you check whether your content overlaps the cutout and reposition things if needed.
<style name="ActivityTheme"> <item name="android:windowLayoutInDisplayCutoutMode"> default/shortEdges/never </item> </style>
Attribute for setting layoutInDisplayCutoutMode from the Activity's theme.
For devices running Android 8.1 (API 27), we've also back-ported the layoutInDisplayCutoutMode activity theme attribute so you can control the display of your content in the cutout area. Note that support on devices running Android 8.1 or lower is up to the device manufacturer, however.
To make it easier to manage your cutout implementation across API levels, we've also added DisplayCutoutCompat in the AndroidX library, which is now available through the SDK manager.
For more about the display cutout APIs, take a look at the documentation.
We strongly recommend testing all screens and experiences of your app to make sure that they work well on cutout devices. We recommend using one of the Android P Beta Devices that features a cutout, such as the Essential PH-1.
If you don't have a device, you can also test using a simulated cutout on any device running Android P or in the Android Emulator. This should help you uncover any issues that your app may run into on devices with cutouts, whether they are running Android 8.1 or Android P.
Android P introduces official platform support for display cutouts, with APIs that you can use to show your content inside or outside of the cutout. To ensure consistency and app compatibility, we're working with our device manufacturer partners to mandate a few requirements.
First, devices must ensure that their cutouts do not negatively affect apps. There are two key requirements:
Second, devices may only have up to one cutout on each short edge of the device. This means that:
Within these constraints, devices can place cutouts wherever they want.
Some devices running Android 8.1 (API level 27) or earlier may optionally support a "special mode" that lets users extend a letterboxed fullscreen or landscape app into the cutout area. Devices would typically offer this mode through a toggle in the navigation bar, which would then bring up a confirmation dialog before extending the screen.
Devices that offer "special mode" allow users to optionally extend apps into the cutout area if supported by the app.
If your app's targetSdkVersion is 27 or higher, you can set the layoutInDisplayCutoutMode activity theme attribute to opt-out of special mode if needed.
While you are working on cutout support, it's also a great time to make sure your app works well on devices with 18:9 or larger aspect ratios, especially since these devices are becoming increasingly common and can feature display cutouts.
We highly encourage you to support flexible aspect ratios so that your app can leverage the full display area, no matter what device it's on. You should test your app on different display ratios to make sure it functions properly and looks good.
Here are some guidelines on screens support to keep in mind as you are developing, also refer to our earlier post on larger aspect ratios for tips on optimizing. If your app can't adapt to the aspect ratios on long screens, you can choose to declare a max aspect ratio to request letterboxing on those screens.
Thanks for reading, and we hope this helps you deliver a delightful experience to all your users, whatever display they may have!
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.
While applications can hook into BiometricPrompt directly for Android 9 and higher, developers should use the BiometricPrompt library to support the widest range of devices.
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 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
