What’s new in Android: the N-Release, Virtual Reality, Android Studio 2.2 and more

What’s new in Android: the N-Release, Virtual Reality, Android Studio 2.2 and more

Android Android N Android Studio Develop Featured Virtual Reality

Posted by Dave Burke, VP of Engineering



In the past year, Android users around the globe have installed apps–built by developers like you–over 65 billion times on Google Play. To help developers continue to build amazing experiences on top of Android, today at Google I/O, we announced a number of new things we’re doing with the platform, including the next Developer Preview of Android N, an extension of Android into virtual reality, an update to Android Studio, and much more!

Android N Developer Preview is available to try on a range of devices

Android N: Performance, Productivity and Security

With Android N, we want to achieve a new level of product excellence for Android, so we’ve carried out some pretty deep surgery to the platform, rewriting and redesigning some fundamental aspects of how the system works. For Android N, we are focused on three key themes: performance, productivity and security. The first Developer Preview introduced a brand new JIT compiler to improve software performance, make app installs faster, and take up less storage. The second N Developer Preview included Vulkan, a new 3D rendering API to help game developers deliver high performance graphics on mobile devices. Both previews also brought useful productivity improvements to Android, including Multi-Window support and Direct Reply.

Multi-Window mode on Android N

Android N also adds some important new features to help keep users safer and more secure. Inspired by how Chromebooks apply updates, we’re introducing seamless updates, so that new Android devices built on N can install system updates in the background. This means that the next time a user powers up their device, new devices can automatically and seamlessly switch into the new updated system image.



Today’s release of Android N Developer Preview 3 is our first beta-quality candidate, available to test on your primary phone or tablet. You can opt in to the Android Beta Program at android.com/beta and run Android N on your Nexus 6, 9, 5X, 6P, Nexus Player, Pixel C, and Android One (General Mobile 4G). By inviting more people to try this beta release, developers can expect to see an uptick in usage of your apps on N; if you’ve got an Android app, you should be testing how it works on N, and be watching for feedback from users.



VR Mode in Android  

Android was built for today’s multi-screen world; in fact, Android powers your phone, your tablet, the watch on your wrist, it even works in your car and in your living room, all the while helping you move seamlessly between each device. As we look to what’s next, we believe your phone can be a really powerful new way to see the world and experience new content virtually, in a more immersive way; but, until this point, high quality mobile VR wasn’t possible across the Android ecosystem. That’s why we’ve worked at all levels of the Android stack in N–from how the operating system reads sensor data to how it sends pixels to the display–to make it especially built to provide high quality mobile VR experiences, with VR Mode in Android. There are a number of performance enhancements designed for developers, including single buffer rendering and access to an exclusive CPU core for VR apps. Within your apps, you can take advantage of smooth head-tracking and stereo notifications that work for VR. Most importantly, Android N provides for very low latency graphics; in fact, motion-to-photon latency on Nexus 6P running Developer Preview 3 is <20 ms, the speed necessary to establish immersion for the user to feel like they are actually in another place. We’ll be covering all of the new VR updates tomorrow at 9AM PT in the VR at Google session, livestreamed from Google I/O.



Android Instant Apps: real apps, without the installation 

We want to make it easier for users to discover and use your apps. So what if your app was just a tap away? What if users didn't have to install it at all? Today, we're introducing Android Instant Apps as part of our effort to evolve the way we think about apps. Whether someone discovers your app from search, social media, messaging or other deep links, they’ll be able to experience a fast and powerful native Android app without needing to stop and install your app first or reauthenticate. Best of all, Android Instant Apps is compatible with all Android devices running Jellybean or higher (4.1+) with Google Play services. Android Instant Apps functionality is an upgrade to your existing Android app, not a new, separate app; you can sign-up to request early access to the documentation.



Android Wear 2.0: UI changes and standalone apps  

This morning at Google I/O, we also announced the most significant Android Wear update since its launch two years ago: Android Wear 2.0. Based on what we’ve learned from users and developers, we're evolving the platform to improve key watch experiences: watch faces, messaging, and fitness. We’re also making a number of UI changes and updating our design guidelines to make your apps more consistent, intuitive, and beautiful.  With Android Wear 2.0, apps can be standalone and have direct network access to the cloud via a Bluetooth, Wi-Fi, or cellular connection.  Since your app won’t have to rely on the Data Layer APIs, it can continue to offer full functionality even if the paired phone is far away or turned off. You can read about all of the new features available in today’s preview here.

Android Studio 2.2 Preview: a new layout designer, constraint layout, and much more

Android Studio is the quickest way to get up and running with Android N and all our new platform features. Today at Google I/O, we previewed Android Studio 2.2 - another big update to the IDE designed to help you code faster with smart new tooling features built in. One of the headline features is our rewritten layout designer with the new constraint layout. In addition to helping you get out of XML to do your layouts visually, the new tools help you easily design for Android’s many great devices. Once you’re happy with a layout, we do all the hard work to automatically calculate constraints for you, so your UIs will resize automatically on different screen sizes . Here’s an overview of more of what’s new in 2.2 Preview (we’ll be diving into more detail this update at 10AM PT tomorrow in “What’s new in Android Development Tools”, livestreamed from Google I/O):

• Speed: New layout designer and constraint layout, Espresso test recording and even faster builds


• Smarts: APK analyzer, Layout inspector, expanded Android code analysis and IntelliJ 2016.1


• Platform Support: Enhanced Jack compiler / Java 8 support, Expanded C++ support with CMake and NDK-Build, Firebase support and enhanced accessibility

New Layout Editor and Constraint Layout in Android Studio 2.2 Preview

This is just a small taste of some of the new updates for Android, announced today at Google I/O. There are more than 50 Android-related sessions over the next three days; if you’re not able to join us in person, many of them will be livestreamed, and all of them will be posted to YouTube after we’re done. We can’t wait to see what you build!

Designing for Multi-Window

Designing for Multi-Window

Android Android N Develop Featured Multiwindow

Posted by Ian Lake, Developer Advocate

As a developer, there’s a wide range of features added in Android N to take advantage of, but when it comes to designing and building your UI, having strong multi-window support should be at the forefront.

The primary mode that users will be interacting with multi-window is through split-screen mode, which is available on both handheld devices and larger tablets. In this mode,
two apps split the available screen space and the user can drag the divider
between the two split screens to resize the apps. As you might imagine, this
mode offers some unique design challenges beyond what was needed previously.

An even more responsive UI

The lessons learned from previous versions of Android, the mobile web, and
desktop environments still apply to Android N. Designing a responsive UI is still an important first step towards an amazing multi-window experience.

A responsive UI is one that adapts to the size provided, picking the best
representation of the content and the appropriate navigation patterns to make a great user experience on any device. Check out the Building a Responsive UI blog post for details on how to design and build an effective responsive UI.

Adapting your layout

As you’re designing layouts for the largest and smallest screens and everything
in between, it is important to make resizing a smooth and seamless transition
as mentioned in the split screen layout guidelines. If you already have a similar layout between mobile and tablet, you’ll find
much of your work taken care of for you.

However, if your mobile and tablet layouts are vastly different and there’s no
way to smoothly transition between the two, you should not transition between them when resizing. Instead, focus on making your tablet UI scale down using the
same responsive UI patterns. This ensures that users do not have to relearn
their UI when resizing your app.

Note that the minimalHeight and minimalWidth layout attributes allow you to set a minimum size you want reported to your Activity, but they
do not mean the user cannot resize your activity smaller - it actually means that
your activity will be cropped to the size the user requests, potentially
forcing elements of your UI off the screen. Strive to support down to the
minimum size of 220x220dp.

Design configurations to consider

While many of the sizes and aspect ratios possible in multi-window are similar
to existing devices (1/3rd of a landscape tablet is similar to existing mobile
devices in screen size), there are a few configurations that are much more
common when considering multi-window.

The first is a 16x9 layout on mobile devices in portrait. In this case, the
vertical space is extremely limited. If you have a number of fixed elements
stacked on top of one another (a toolbar, scrolling content, and a bottom
navigation bar), you might find there’s not actually any room for the scrolling
content - the most important part!

The second case to consider is the 34.15% layout on tablets. The very wide
aspect ratio in device portrait or very tall aspect ratio in device landscape
orientation are more extreme than what is found on existing devices. Consider
using your mobile layouts as a starting point for this configuration.

Patterns to avoid

When it comes to multi-window, there are a few patterns you want to avoid
entirely.

The first is UI interactions that rely on swiping from the edge of the screen.
This has already been somewhat of an issue when it comes to the on screen
navigation bar prominent on many devices (such as Nexus devices), but is even
more so in split-screen mode. Since there is (purposefully) no way to determine
if your activity is on the top or bottom or the left or the right, don’t make edge swipes the only way to access functionality in your app. That doesn’t mean you have to avoid them entirely - just make sure there is
an alternative. A good example of this is the temporary navigation drawer - an edge swipe opens the drawer, but it is also accessible by pressing the
hamburger icon in the toolbar.

The second is disabling multi-window entirely. While there are certainly cases
where this makes sense (i.e., it is fundamentally an immersive experience such
as a game), there are also cases where your activity and any Activities
launched from that Activity are forced to support multi-window. As mentioned in the Preparing for Multi-Window blog post, when you support external apps launching your activity, your activity inherits the multi-window properties of the calling Activity.

Designing for Multi-Window is designing for every device

Building a responsive UI that reacts to the space available is critical to a
great multi-window experience, but it is an exercise that can benefit all of
your users across the wide variety of Android devices.

So use this as an opportunity to #BuildBetterApps

Follow the Android Development Patterns Collection for more!

Hardening the media stack

Hardening the media stack

Android Android N Develop Featured Security

Posted by Dan Austin and Jeff Vander Stoep, Android Security team

To help make Android more secure, we encourage and reward researchers who discover vulnerabilities. In 2015, a series of bugs in
mediaserver’s libstagefright were disclosed to Google. We released updates for
these issues with our August and September 2015 security bulletins.

In addition to addressing issues on a monthly basis, we’ve also been working on
new security features designed to enhance the existing security model and
provide additional defense in-depth. These defense measures attempt to achieve
two goals:

• Prevention: Stop bugs from becoming vulnerabilities
  
• Containment: Protect the system by de-privileging and isolating components that handle
  untrusted content
  

Prevention

Most of the vulnerabilities found in libstagefright were heap overflows
resulting from unsigned integer overflows. A number of integer overflows in libstagefright allowed an attacker to
allocate a buffer with less space than necessary for the incoming data,
resulting in a buffer overflow in the heap.

The result of an unsigned integer overflow is well defined, but the ensuing
behavior could be unexpected or unsafe. In contrast, signed integer overflows
are considered undefined behavior in C/C++, which means the result of an
overflow is not guaranteed, and the compiler author may choose the resulting
behavior—typically what is fastest or simplest. We have added compiler changes
that are designed to provide safer defaults for both signed and unsigned
integer overflows.

The UndefinedBehaviorSanitizer (UBSan) is part of the LLVM/Clang compiler toolchain that detects undefined or
unintended behavior. UBSan can check for multiple types of undefined and unsafe
behavior, including signed and unsigned integer overflow. These checks add code
to the resulting executable, testing for integer overflow conditions during
runtime. For example, figure 1 shows source code for the parseChunk function in the MPEG4Extractor component of libstagefright after the original researcher-supplied patch was
applied. The modification, which is contained in the black box below, appears
to prevent integer overflows from occurring. Unfortunately, while SIZE_MAX and size are 32-bit values, chunk_size is a 64-bit value, resulting in an incomplete check and the potential for
integer overflow. In the line within the red box, the addition of size and chunk_size may result in an integer overflow and creation of buffer smaller than size elements. The subsequent memcpy could then lead to exploitable memory corruption, as size + chunk_size could be less than size, which is highlighted in the blue box. The mechanics of a potential exploit
vector for this vulnerability are explained in more detail by Project Zero.

Figure 1. Source code demonstrating a subtle unsigned integer overflow.

Figure 2 compares assembly generated from the code segment above with a second
version compiled with integer sanitization enabled. The add operation that
results in the integer overflow is contained in the red box.

In the unsanitized version, size (r6) and chunk_size (r7) are added together, potentially resulting in r0 overflowing and being less than size. Then, buffer is allocated with the size specified in r0, and size bytes are copied to it. If r0 is less than r6, this results in memory corruption.

In the sanitized version, size (r7) and chunk_size (r5) are added together with the result stored in r0. Later, r0 is checked against r7, if r0 is less than r7, as indicated by the CC condition code, r3 is set to 1. If r3 is 1, and the carry bit was set, then an integer overflow occurred, and an
abort is triggered, preventing memory corruption.

Note that the incomplete check provided in the patch was not included in figure
2. The overflow occurs in the buffer allocation’s add operation. This addition triggers an integer sanitization check, which turns
this exploitable flaw into a harmless abort.

Figure 2. Comparing unsanitized and sanitized compiler output.

While the integer sanitizers were originally intended as code hygiene tools,
they effectively prevent the majority of reported libstagefright
vulnerabilities. Turning on the integer overflow checks was just the first
step. Preventing the runtime abort by finding and fixing integer overflows,
most of which are not exploitable, represented a large effort by Android's
media team. Most of the discovered overflows were fixed and those that remain
(mostly for performance reasons) were verified and marked as safe to prevent
the runtime abort.

In Android N, signed and unsigned integer overflow detection is enabled on the
entire media stack, including libstagefright. This makes it harder to exploit
integer overflows, and also helps to prevent future additions to Android from
introducing new integer overflow bugs.

Containment

For Android M and earlier, the mediaserver process in Android was responsible
for most media-related tasks. This meant that it required access to all
permissions needed by those responsibilities and, although mediaserver ran in
its own sandbox, it still had access to a lot of resources and capabilities.
This is why the libstagefright bugs from 2015 were significant—mediaserver
could access several important resources on an Android device including camera,
microphone, graphics, phone, Bluetooth, and internet.

A root cause analysis showed that the libstagefright bugs primarily occurred in
code responsible for parsing file formats and media codecs. This is not
surprising—parsing complex file formats and codecs while trying to optimize for
speed is hard, and the large number of edge cases makes such code susceptible
to both accidental and malicious malformed inputs.

However, media parsers do not require access to most of the privileged
permissions held by mediaserver. Because of this, the media team re-architected
mediaserver in Android N to better adhere to the principle of least privilege.
Figure 3 illustrates how the monolithic mediaserver and its permissions have
been divided, using the following heuristics:

• parsing code moved into unprivileged sandboxes that have few or no permissions
  
• components that require sensitive permissions moved into separate sandboxes
  that only grant access to the specific resources the component needs. For
  example, only the cameraserver may access the camera, only the audioserver may
  access Bluetooth, and only the drmserver may access DRM resources.
  

Figure 3. How mediaserver and its permissions have been divided in Android N.

Comparing the potential impact of the libstagefright bugs on Android N and
older versions demonstrates the value of this strategy. Gaining code execution
in libstagefright previously granted access to all the permissions and
resources available to the monolithic mediaserver process including graphics
driver, camera driver, or sockets, which present a rich kernel attack surface.

In Android N, libstagefright runs within the mediacodec sandbox with access to
very few permissions. Access to camera, microphone, photos, phone, Bluetooth,
and internet as well as dynamic code loading are disallowed by SELinux. Interaction with the kernel is further restricted by seccomp. This means that compromising libstagefright would grant the attacker access
to significantly fewer permissions and also mitigates privilege escalation by
reducing the attack surface exposed by the kernel.

Conclusion

The media hardening project is an ongoing effort focused on moving
functionality into less privileged sandboxes and further reducing the
permissions granted to those sandboxes. While the techniques discussed here
were applied to the Android media framework, they are suitable across the
Android codebase. These hardening techniques—and others—are being actively
applied to additional components within Android. As always, we appreciate
feedback on our work and welcome suggestions for how we can improve Android.
Contact us at security@android.com.

Developing for Direct Boot

Developing for Direct Boot

Android Android N Featured

Posted by Wojtek Kaliciński, Developer Advocate

Starting with Android N, a device that has been powered on can boot into a new mode called Direct Boot before the user has a chance to unlock it for the first time. In this mode, the operating system is fully operational, but access to private app data is limited and only apps that have been updated to be Direct Boot aware can run.

Is Direct Boot right for my app?

Not every app should run in Direct Boot mode, so before you start coding check if your app fits these common use cases:

• Apps that schedule alarms, such as alarm clocks.


• Apps that provide important and timely notifications, like messaging apps.


• Apps that provide services to other apps or the system, such as Accessibility Services.

Please note that this is not an exhaustive list and we look forward to seeing what other kinds of apps can benefit from Direct Boot.

Making your app Direct Boot aware

In order to let your app run before the user unlocks the device, you have to explicitly mark components as being Direct Boot aware in the manifest:

 <activity|provider|receiver|service ...  
     android:directBootAware=”true”>  

You can pick the subset of your app components that need to be Direct Boot aware, but if you are using a custom Application class, it is assumed to be Direct Boot aware if any component inside your app is marked as Direct Boot aware.

For apps that need to run as soon as the system starts in Direct Boot mode, there is a new Intent.ACTION_LOCKED_BOOT_COMPLETED broadcast. All apps will still receive Intent.ACTION_BOOT_COMPLETED after the user unlocks the device.

Using the device protected storage area

To support running apps before the user provides the credentials needed to unlock private app data, all Android N devices now provide two storage locations for data:

• Credential protected storage, which is the default storage location for all apps, available only after the user has unlocked the device


• Device protected storage, which is a new storage location that can be accessed at all times when the device is booted, including during Direct Boot

Components of your app that are marked as Direct Boot aware must rely on device protected storage for any data required for their operation during Direct Boot mode. They may still access credential protected storage after the user has unlocked the device.

To access device protected storage you need to create and use a secondary Context object for all file-related APIs:

 Context deviceProtectedContext = context.createDeviceProtectedStorageContext();  
 deviceProtectedContext.openFileInput( ... )  

When your app gets updated to a Direct Boot aware version, you might have previously saved Shared Preferences or databases that need to be migrated to device protected storage. You should use Context.moveSharedPreferencesFrom() and Context.moveDatabaseFrom() before accessing them to make sure the app continues to work properly even when data is backed up and restored from older versions or other devices.

Things to watch out for

You should think carefully about what you put in the device protected storage. This should be a minimum set of data that will let your app work during Direct Boot. For example, in a messaging app you could store an access token with a narrow scope that only has access to the number of new messages on your server. All sensitive, private information, like the full message history and a read/write access token, should still be saved in credential protected storage.

Another thing to remember is that during Direct Boot apps can only access other Direct Boot aware apps and components. If your app depends on external Services and Activities, make sure you gracefully handle the situation when they’re not available. Intent filters will by default match only components available in the current user state (locked / unlocked). There are two new flags for explicitly telling the Package Manager which components to enumerate: PackageManager.MATCH_DIRECT_BOOT_AWARE and PackageManager.MATCH_DIRECT_BOOT_UNAWARE.

What’s next?

Until devices with Android N that support Direct Boot out of the box are released, you can test your apps using Android N Developer Preview builds. On Nexus 5X and Nexus 6P, you can wipe all user data and enable full Direct Boot mode by using Settings > Developer options > Convert to file encryption. Alternatively, you can reboot into bootloader and issue the appropriate fastboot command:

 $ adb reboot-bootloader  
 $ fastboot --wipe-and-use-fbe  

Warning: Both methods will perform a factory reset and delete all user data on your device.

Alternatively, you can use an emulated Direct Boot mode. To enable it, set a lock pattern on the device, choose "No thanks" if prompted for a secure start-up screen when setting a lock pattern, and then use the following adb shell commands to enable and disable emulation:

 $ adb shell sm set-emulate-fbe true  
 $ adb shell sm set-emulate-fbe false  

Please note that using these commands will cause your device to reboot. You should only be using emulated Direct Boot mode on test devices, as it may cause data loss.

#BuildBetterApps

Follow the Android Development Patterns Collection for more!

Android Studio 2.1 supports Android N Developer Preview

Android Studio 2.1 supports Android N Developer Preview

Android Android N Android Studio Develop Featured

Posted by Jamal Eason, Product Manager, Android

With the launch Android N Developer Preview, we wanted to give you an easy and comprehensive way to build, test and validate your apps on the latest release with Android Studio. Built on the speed and feature enhancements of Android Studio 2.0, the stable release of Android Studio 2.1 includes updates to the IDE wizards, build system and Android Emulator so that you can try out new features and APIs of the developer preview including the new Jack compiler and Java 8 language support. In addition to support for the N Developer Preview, Android Studio 2.1 also includes performance improvements to Instant Run which leads to faster edit and deploy build speeds. If you are developing and validating your app with the N Developer Preview or want faster Instant Run speeds, you should download or update on the stable release channel to Android Studio 2.1.

Android Studio 2.1 includes the following new features:

• N Developer Preview Support: Android Studio 2.1 is the best IDE to test and validate your app with the N Developer Preview. Get the latest versions of the preview SDK, experiment with the new Java 8 support, and gain access to the only official Android Emulator able to run N Developer Preview Emulator System Images to help in your testing.


• Instant Run: For those of you who enjoyed the fast edit, build and deploy cycle with Android Studio 2.0, Instant Run now can now update incremental changes to your app code significantly faster.

Deeper Dive into the New Features

N Developer Preview

On top of new features and APIs of the N Developer Preview, Android Studio 2.1 release includes support for the new Jack compiler and support for Java 8. With the Jack compiler, lambdas, method references, compile-time type annotations, intersection types and type inference are available on all versions of the Android platform. Default and static methods and repeatable annotations are available on Android N and higher. To use Java 8 language features when developing with the N Developer Preview, you need to use the Jack compiler. The New Project Wizard [File→ New→ Project] generates the correct configurations for projects targeting the N.

Getting started with development is as easy generating a new project or updating a few settings in your existing project. Once you are ready to test, you can create a fresh Android Virtual Device (AVD) and run your app on the N Developer Preview using the new Android Emulator.

N Developer Preview on the new Android Emulator

Instant Run & General Build Performance Improvements

Instant Run and general build speed are now faster with two new features: incremental Java compilation and in-process dex.

In previous versions of Android Studio, a single line of Java code change will cause all the Java sources in the module to be recompiled. Now in Android Studio 2.1, incremental Java compilation is enabled by default to reduce compilation time by compiling only what is needed.

We are also speeding up build times by using in-process dex, which converts class files to dex files within the Gradle daemon process. This avoids the costly processing operation of creating separate dex processes. To use this feature, you will need to increase the amount of memory available to the Gradle daemon to at least 2GB (1 GB is the default). This feature will help speed up both incremental and full builds.

We’d appreciate your feedback as we continue to improve Instant Run and general build performance. We are going to keep working on making build times even faster in coming releases. Click here to learn even more about the build changes.

What's Next

Update

If you are using a previous version of Android Studio, you can check for updates on the Stable channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). If you need a new copy of Android Studio, you can download it here.

Test and Validate Apps with N Developer Preview

After you update to or download Android Studio 2.1 and you want to test and develop your apps with the N Developer Preview, create a fresh Android Virtual Device (AVD) for the new Android emulator, and check out these additional setup instructions.

We appreciate any feedback on things you like, issues or features you would like to see. Connect with us -- the Android Studio development team -- on our Google+ page or on Twitter.

Protecting against unintentional regressions to cleartext traffic in your Android apps

Protecting against unintentional regressions to cleartext traffic in your Android apps

Android Android N Featured HTTPS Security

Posted by Alex Klyubin, Android Security team

When your app communicates with servers using cleartext network traffic, such as HTTP, the traffic risks being eavesdropped upon and tampered with by third parties. This may leak information about your users and open your app up to injection of unauthorized content or exploits. Ideally, your app should use secure traffic only, such as by using HTTPS instead of HTTP. Such traffic is protected against eavesdropping and tampering.

Many Android apps already use secure traffic only. However, some of them occasionally regress to cleartext traffic by accident. For example, an inadvertent change in one of the server components could make the server provide the app with HTTP URLs instead of HTTPS URLs. The app would then proceed to communicate in cleartext, without any user-visible symptoms. This situation may go unnoticed by the app’s developer and users.

Even if you believe your app is only using secure traffic, make sure to use the new mechanisms provided by Android Marshmallow (Android 6.0) to catch and prevent accidental regressions.

New protection mechanisms

For apps which only use secure traffic, Android 6.0 Marshmallow (API Level 23) introduced two mechanisms to address regressions to cleartext traffic: (1) in production / installed base, block cleartext traffic, and (2) during development / QA, log or crash whenever non-TLS/SSL traffic is encountered. The following sections provide more information about these mechanisms.

Block cleartext traffic in production

To protect the installed base of your app against regressions to cleartext traffic, declare android:usesCleartextTraffic=”false” attribute on the application element in your app’s AndroidManifest.xml. This declares that the app is not supposed to use cleartext network traffic and makes the platform network stacks of Android Marshmallow block cleartext traffic in the app. For example, if your app accidentally attempts to sign in the user via a cleartext HTTP request, the request will be blocked and the user’s identity and password will not leak to the network.

You don’t have to set minSdkVersion or targetSdkVersion of your app to 23 (Android Marshmallow) to use android:usesCleartextTraffic. On older platforms, this attribute is simply ignored and thus has no effect.

Please note that WebView does not yet honor this feature.

And under certain circumstances cleartext traffic may still leave or enter the app. For example, Socket API ignores the cleartext policy because it does not know whether the data it transmits or receives can be classified as cleartext. Android platform HTTP stacks, on the other hand, honor the policy because they know whether traffic is cleartext.

Google AdMob is also built to honor this policy. When your app declares that it does not use cleartext traffic, only HTTPS-only ads should be served to the app.

Third-party network, ad, and analytics libraries are encouraged to add support for this policy. They can query the cleartext traffic policy via the NetworkSecurityPolicy class.

Detect cleartext traffic during development

To spot cleartext traffic during development or QA, StrictMode API lets you modify your app to detect non-TLS/SSL traffic and then either log violations to system log or crash the app (see StrictMode.VmPolicy.Builder.detectCleartextNetwork()). This is a useful tool for identifying which bits of the app are using non-TLS/SSL (and DLTS) traffic. Unlike the android:usesCleartextTraffic attribute, this feature is not meant to be enabled in app builds distributed to users.

Firstly, this feature is supposed to flag secure traffic that is not TLS/SSL. More importantly, TLS/SSL traffic via HTTP proxy also may be flagged. This is an issue because as a developer, you have no control over whether a particular user of your app may have configured their Android device to use an HTTP proxy. Finally, the implementation of the feature is not future-proof and thus may reject future TLS/SSL protocol versions. Thus, this feature is intended to be used only during the development and QA phase.

Declare finer-grained cleartext policy in Network Security Config

Android N offers finer-grained control over cleartext traffic policy. As opposed to android:usesCleartextTraffic attribute, which applies to all destinations with which an app communicates, Android N’s Network Security Config lets an app specify cleartext policy for specific destinations. For example, to facilitate a more gradual transition towards a policy that does not allow cleartext traffic, an app can at first block accidental cleartext only for communication with its most important backends and permit cleartext to be used for other destinations.

Next steps

It is a security best practice to only use secure network traffic for communication between your app and its servers. Android Marshmallow enables you to enforce this practice, so give it a try!

As always, we appreciate feedback and welcome suggestions for improving Android. Contact us at security@android.com.

Android N Developer Preview 2, out today!

Android N Developer Preview 2, out today!

Android Android N Develop

Posted by Dave Burke, VP of Engineering

Last month, we released the first Developer Preview of Android N, to give you a sneak peek at our next platform. The feedback you’ve shared to-date has helped us catch bugs and improve features. Today, the second release in our series of Developer Previews is ready for you to continue testing against your apps.

This latest preview of Android N fixes a few bugs you helped us identify, such as not being able to connect to hidden Wi-Fi networks (AOSP 203116), Multiwindow pauses (AOSP 203424), and Direct Reply closing an open activity (AOSP 204411), to name just a few. We’re still on the hunt for more; please continue to share feedback, either in the N Developer Preview issue tracker or in the N preview community.

What’s new:

Last month’s Developer Preview introduced a host of new features, like Multi-window, bundled notifications and more. This preview builds on those and includes a few new ones:

• Vulkan: Vulkan is a new 3D rendering API which we’ve helped to develop as a member of Khronos, geared at providing explicit, low-overhead GPU (Graphics Processor Unit) control to developers and offers a significant boost in performance for draw-call heavy applications. Vulkan’s reduction of CPU overhead allows some synthetic benchmarks to see as much as 10 times the draw-call throughput on a single core as compared to OpenGL ES. Combined with a threading-friendly API design which allows multiple cores to be used in parallel with high efficiency, this offers a significant boost in performance for draw-call heavy applications. With Android N, we’ve made Vulkan a part of the platform; you can try it out on supported devices running Developer Preview 2. Read more here. Vulkan Developer Tools blog here.



• Launcher shortcuts: Now, apps can define shortcuts which users can expose in the launcher to help them perform actions quicker. These shortcuts contain an Intent into specific points within your app (like sending a message to your best friend, navigating home in a mapping app, or playing the next episode of a TV show in a media app).
  

  An application can publish shortcuts with ShortcutManager.setDynamicShortcuts(List) and ShortcutManager.addDynamicShortcut(ShortcutInfo), and launchers can be expected to show 3-5 shortcuts for a given app.




• Emoji Unicode 9 support: We are introducing a new emoji design for people emoji that moves away from our generic look in favor of a more human-looking design. If you’re a keyboard or messaging app developer, you should start incorporating these emoji into your apps.
  The update also introduces support for skin tone variations and Unicode 9 glyphs, like the bacon, selfie and face palm. You can dynamically check for the new emoji characters using Paint.hasGlyph().
• 
  

New human emoji

New activity emoji

• API changes: This update includes API changes as we continue to refine features such as multi-window support (you can now specify a separate minimum height and minimum width for an activity), notifications, and others. For details, take a look at the diff reports available in the downloadable API reference package.




• Bug fixes: We’ve resolved a number of issues throughout the system, including these fixes for issues that you’ve reported through the public issue tracker. Please continue to let us know what you find and follow along with the known issues here.

How to get the update:

The easiest way to get this and later preview updates is by enrolling your devices in the Android Beta Program. Just visit g.co/androidbeta and opt-in your eligible Android phone or tablet -- you’ll soon receive this (and later) preview updates over-the-air. If you’ve already enrolled your device, you’ll receive the update shortly, no action is needed on your part. You can also download and flash this update manually. Developer Preview 2 is intended for developers and not as a daily driver; this build is not yet optimized for performance and battery life.

The N Developer Preview is currently available for Nexus 6, Nexus 5X, Nexus 6P, Nexus 9, and Pixel C devices, as well as General Mobile 4G [Android One] devices. For Nexus Player, the update to Developer Preview 2 will follow the other devices by several days.

To build and test apps with Developer Preview 2, you need to use Android Studio 2.1 -- the same version that was required for Developer Preview 1. You’ll need to check for SDK components updates (including build tools and emulator system images) for Developer Preview 2 -- see here for details.

Thanks so much for all of your feedback so far. Please continue to share feedback, either in the N Developer Preview issue tracker or in the N preview community. The sooner we’re able to get your feedback, the more of of it we will be able to incorporate in the next release of Android.