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
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:
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.
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:
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.
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.
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 Code → Convert 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.
build.gradle
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.
To recap, Android Studio 3.0 includes these new major features:
Develop
Build
Optimize
Check out the release notes for more details.
Download
Test & Debug
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
Since our public launch at Google I/O, we've been working hard to improve the developer experience of building instant apps. Today, we're excited to announce availability of the Android Instant Apps SDK 1.1 with some highly-requested features such as improved NDK support, configuration APKs for binary size reduction, and a new API to maintain user's context when they transition from an instant app to the installed app.
For a great instant app experience, app binaries need to be lean and well structured. That's why we're introducing configuration APKs.
Configuration APKs allow developers to isolate device-specific resources and native libraries into independent APKs. For an application that uses configuration APKs, the Android Instant Apps framework will only load the resources and native libraries relevant to the user's device, thereby reducing the total size of the instant app on the device.
We currently support configuration APKs for display density, CPU architecture (ABI), and language. With these, we have seen an average reduction of 10% in the size of the binaries loaded. Actual savings for a given app depend on the number of resource files and native libraries that can be configured.
As an example, a user on an ARM device with LDPI screen density and language set to Chinese would then receive device-agnostic code and resources, and then only get the configuration APKs that have ARM native libraries, the Chinese language, and LDPI resources. They would not receive any of the other configuration APKs such as the x86 libraries, Spanish language strings, or HDPI resources.
Setting up configuration APKs for your app is a simple change to your gradle setup. Just follow the steps in our public documentation.
On Android Oreo, the internal storage of the instant version of the app is directly available to the installed version of the app. With this release of the SDK, we are enabling this functionality on older versions of the Android Framework, including Lollipop, Marshmallow, and Nougat devices.
To extract the internal storage of the instant app, installed apps can now call InstantAppsClient.getInstantAppData() using the Instant Apps Google Play Services API and get a ZIP file of the instant app's internal storage.
Check out our code sample and documentation for more details on how to use this API.
It's simple to start building your instant app on the latest SDK. Just open the SDK Manager in Android Studio and update your Instant Apps Development SDK to 1.1.0. We can't wait to see what instant app experiences you build with these new features.
Since announcing ConstraintLayout at Google I/O last year, we've continued to improve the layout's stability and layout editor support. We've also added new features specific to ConstraintLayout that help you build various type of layouts, such as introducing chains and setting size as a ratio. In addition to these features, there is a notable performance benefit by using ConstraintLayout. In this post, we'll walk through how you can benefit from these performance improvements.
ConstraintLayout
To better understand the performance of ConstraintLayout, let's take a step back and see how Android draws views.
When a user brings an Android view into focus, the Android framework directs the view to draw itself. This drawing process comprises 3 phases:
The system completes a top-down traversal of the view tree to determine how large each ViewGroup and View element should be. When a ViewGroup is measured, it also measures its children.
ViewGroup
Another top-down traversal occurs, with each ViewGroup determining the positions of its children using the sizes determined in the measure phase.
The system performs yet another top-down traversal. For each object in the view tree, a Canvas object is created to send a list of drawing commands to the GPU. These commands include the ViewGroup and View objects' sizes and positions, which the system determined during the previous 2 phases.
Canvas
View
Each phase within the drawing process requires a top-down traversal of the view tree. Therefore, the more views you embed within each other (or nest) into the view hierarchy, the more time and computation power it takes for the device to draw the views. By keeping a flat hierarchy in your Android app layouts, you can create a fast and responsive user interface for your app.
With that explanation in mind, let's create a traditional layout hierarchy that uses LinearLayout and RelativeLayout objects.
LinearLayout
RelativeLayout
Let's say we want to build a layout like the image above. If you build it with traditional layouts, the XML file contains an element hierarchy similar to the following (for this example, we've omitted the attributes):
<RelativeLayout> <ImageView /> <ImageView /> <RelativeLayout> <TextView /> <LinearLayout> <TextView /> <RelativeLayout> <EditText /> </RelativeLayout> </LinearLayout> <LinearLayout> <TextView /> <RelativeLayout> <EditText /> </RelativeLayout> </LinearLayout> <TextView /> </RelativeLayout> <LinearLayout > <Button /> <Button /> </LinearLayout> </RelativeLayout>
Although there's usually room for improvement in this type of view hierarchy, you'll almost certainly still need to create a hierarchy with some nested views.
As discussed before, nested hierarchies can adversely affect performance. Let's take a look at how the nested views actually affect the UI performance using Android Studio's Systrace tool. We called the measure and layout phases for each ViewGroup (ConstraintLayout and RelativeLayout) programmatically and triggered Systrace while the measure and layout calls are executing. The following command generates an overview file that contains key events, such as expensive measure/layout passes, that occur during a 20-second interval:
python $ANDROID_HOME/platform-tools/systrace/systrace.py --time=20 -o ~/trace.html gfx view res
For more details about how you can use Systrace, see the Analyzing UI Performance with Systrace guide.
Systrace automatically highlights the (numerous) performance problems with this layout, as well as suggestions for fixing them. By clicking the "Alerts" tab, you will find that drawing this view hierarchy requires 80 expensive passes through the measure and layout phases!
Triggering that many expensive measure and layout phases is far from ideal; such a large amount of drawing activity could result in skipped frames that users notice. We can conclude that the layout has poor performance due to the nested hierarchy as well as the characteristic of RelativeLayout, which measures each of its children twice.
You can check the entire code on how we performed these measurements in our GitHub repository.
If you create the same layout using ConstraintLayout, the XML file contains an element hierarchy similar to the following (attributes again omitted):
<android.support.constraint.ConstraintLayout> <ImageView /> <ImageView /> <TextView /> <EditText /> <TextView /> <TextView /> <EditText /> <Button /> <Button /> <TextView /> </android.support.constraint.ConstraintLayout>
As this example shows, the layout now has a completely flat hierarchy. This is because ConstraintLayout allows you to build complex layouts without having to nest View and ViewGroup elements.
For example, let's look at the TextView and EditText in the middle of the layout:
TextView
EditText
<LinearLayout android:id="@+id/camera_area" android:layout_width="match_parent" android:layout_height="wrap_content" android:orientation="horizontal" android:layout_below="@id/title" > <TextView android:text="@string/camera" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_gravity="center_vertical" android:id="@+id/cameraLabel" android:labelFor="@+id/cameraType" android:layout_marginStart="16dp" /> <RelativeLayout android:layout_width="match_parent" android:layout_height="wrap_content"> <EditText android:id="@+id/cameraType" android:ems="10" android:inputType="textPersonName" android:text="@string/camera_value" android:layout_width="match_parent" android:layout_height="wrap_content" android:layout_centerVertical="true" android:layout_marginTop="8dp" android:layout_marginStart="8dp" android:layout_marginEnd="8dp" /> </RelativeLayout> </LinearLayout>
By using ConstraintLayout instead, you can achieve the same effect just by adding a constraint from the baseline of the TextView to the baseline of the EditText without creating another ViewGroup:
<TextView android:layout_width="wrap_content" android:layout_height="wrap_content" app:layout_constraintLeft_creator="1" app:layout_constraintBaseline_creator="1" app:layout_constraintLeft_toLeftOf="@+id/activity_main_done" app:layout_constraintBaseline_toBaselineOf="@+id/cameraType" />
When running the Systrace tool for the version of our layout that uses ConstraintLayout, you see far fewer expensive measure/layout passes during the same 20-second interval. This improvement in performance makes sense, now that we're keeping the view hierarchy flat!
On a related note, we built the ConstraintLayout variant of our layout using just the layout editor instead of editing the XML by hand. To achieve the same visual effect using RelativeLayout, we probably would have needed to edit the XML by hand.
We analyzed how long every measure and layout pass took for two type of layouts, ConstraintLayout and RelativeLayout, by using OnFrameMetricsAvailableListener, which was introduced in Android 7.0 (API level 24). This class allows you to collect frame-by-frame timing information about your app's UI rendering.
OnFrameMetricsAvailableListener
By calling the following code, you can start recording per-frame UI actions:
window.addOnFrameMetricsAvailableListener( frameMetricsAvailableListener, frameMetricsHandler);
After timing information becomes available, the app triggers the frameMetricsAvailableListener() callback. We are interested in the measure/layout performance, so we call FrameMetrics.LAYOUT_MEASURE_DURATION when retrieving the actual frame duration.
frameMetricsAvailableListener()
FrameMetrics.LAYOUT_MEASURE_DURATION
Window.OnFrameMetricsAvailableListener { _, frameMetrics, _ -> val frameMetricsCopy = FrameMetrics(frameMetrics); // Layout measure duration in nanoseconds val layoutMeasureDurationNs = frameMetricsCopy.getMetric(FrameMetrics.LAYOUT_MEASURE_DURATION);
To learn more about the other types of duration information that FrameMetrics can receive, see the FrameMetrics API reference.
FrameMetrics
Our performance comparison shows that ConstraintLayout performs about 40% better in the measure/layout phase than RelativeLayout:
As these results show, ConstraintLayout is likely to be more performant than traditional layouts. Moreover, ConstraintLayout has other features that help you build complex and performant layouts, as discussed in the benefits of a ConstraintLayout object section. For details, see the Build a Responsive UI with ConstraintLayout guide. We recommend that you use ConstraintLayout when designing your app's layouts. In almost all cases when you would have previously need a deeply-nested layout, ConstraintLayout should be your go-to layout for optimal performance and ease of use.
All the measurements above were performed in the following environment.
Check out the developer guide, the API reference documentation, and the article on Medium to fully understand what ConstraintLayout can provide for you. And once again, thank you to all who submitted feedback and issues over the months since our alpha release of ConstraintLayout. We're truly grateful that we were able to release the production-ready 1.0 version of ConstraintLayout earlier this year. As we continue to improve ConstraintLayout, please continue to send us feedback using the Android issue tracker.
Android developers know that dex compilation is a key step in building an APK. This is the process of transforming .class bytecode into .dex bytecode for the Android Runtime (or Dalvik, for older versions of Android). The dex compiler mostly works under the hood in your day-to-day app development, but it directly impacts your app's build time, .dex file size, and runtime performance.
That's why we are investing in making important improvements in the dex compiler. We're excited to announce that the next-generation dex compiler, D8, is now available for preview as part of Android Studio 3.0 Beta release.
When comparing with the current DX compiler, D8 compiles faster and outputs smaller .dex files, while having the same or better app runtime performance.
D8 is available for your preview starting with Android Studio 3.0 Beta. To try it, set the following in your project's gradle.properties file:
android.enableD8=true
We have tested D8's correctness and performance on a number of apps, and the results are encouraging. We're confident enough with the results that we are switching to use D8 as the default dex compiler for building AOSP.
Please give D8 a try and we would love to hear your feedback. You can file a bug report using this link.
We plan to preview D8 over the next several months with the Android Studio 3.0 release. During this time, we will focus on addressing any critical bug reports we receive from the community. We plan to bring D8 out of preview and enable it as the default dex compiler in Android Studio 3.1. At that time, the DX compiler will officially be put in maintenance mode. Only critical issues with DX will be fixed moving forward.
Beyond D8, we are also working on R8, which is a Proguard replacement for whole program minification and optimization. While the R8 project has already been open sourced, it has not yet been integrated with the Android Gradle plugin. We will provide more details about R8 in the near future when we are ready to preview it with the community.
In April, we announced Java 8 language features with desugaring. The desugaring step currently happens immediately after Java compilation (javac) and before any bytecode reading or rewriting tools are run. Over the next couple of months, the desugar step will move to a later stage in the pipeline, as part of D8. This will allow us to further reduce the overall build time and produce more optimized code. This change means that any bytecode reading or rewriting tools will run before the desugar step. If you develop .class bytecode reading or rewriting tools for Android, you will need to make sure they can handle the Java 8 bytecode format so they can continue to work properly when we move desugaring into D8.
Happy dex'ing!
Earlier this year, we began testing Android Instant Apps, a new way to run Android apps without requiring installation. Thanks to our incredible developer community, we received a ton of feedback that has helped us refine the end-to-end product experience.
Today, we're opening Android Instant Apps to all developers, so anyone can build and publish an instant app. There are also more than 50 new experiences available for users to try from a variety of developers, such as HotPads, Jet, the New York Times, Vimeo, and One Football. While these experiences have only been live for a short amount of time, the early data shows positive results. For example, Jet and HotPads are seeing double digit increases in purchases and leads generated.
Feedback from our early partners has directly shaped the development tools we're making available to all of you today.
To get started building an instant app, head over to developer.android.com and download the latest preview of Android Studio 3.0 and the Android Instant Apps SDK. You'll continue to use a single codebase. Android Studio provides the tools you need to modularize your app so that features can be downloaded as needed. Every app is different, but we've seen with our early partners that with the latest tools, instant app development typically takes about 4-6 weeks.
Once you've built your app, the Play Console provides support for distributing your instant app. You just upload your instant app APKs together with your installable APK.
Instant Apps continues to ramp up on the latest Android devices in more than 40 countries. And with Android O, we've gone further, building a new, more efficient runtime sandbox for instant apps, sharable support libraries to reduce app size, and launcher integration support.
To learn more, visit g.co/InstantApps. We're also hosting a session "Introduction to Android Instant Apps" on Thursday, May 18 from 1:30-2:30 PM PT at the conference to dig deeper into the topic. You'll also be able to watch the live stream on Google I/O YouTube channel.
We are excited to see what experiences you create with Instant Apps!
Just in time for Google I/O 2017, we're providing a sneak peak of Android Studio 3.0 - available to download today on our canary release channel. Android Studio's our official IDE, purpose-built for Android, and we keep increasing our investment. The feature set in Android Studio is focused on accelerating your app development flow and providing the latest tools built for the Android platform.
dependencies { classpath 'com.android.tools.build:gradle:3.0.0-alpha1' }
repositories { maven { url "https://maven.google.com" } }
If you are using a previous version of Android Studio, you can install Android Studio 3.0 Canary 1 alongside your stable version. You can download this update from the official Android Studio Preview download page. As mention 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-alpha1 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.
Platform
Android Studio
Google Play
Android Jetpack
Docs
News
