Android Studio 2.0 Beta: What’s New?

An Android Tool Time Deep Dive Breakdown

After 10 canary builds, Android Studio is now available in Beta! If you haven’t played with it since the canary launch at the Android Dev Summit, now’s a great time to take a fresh look.

Any time spent waiting for your IDE is time wasted. Time you could be writing code, time that pushes out the end of your day, or a break that risks dropping you out of the zone.

The goal for Android Studio 2.0: Make everything ten times faster. Faster builds, faster deployment, faster emulators. Everything. Faster. The internal codename was “10x”.

Instant Run

Instant Run builds and deploys incremental changes to your app within a few seconds by hot swapping code — injecting changes directly into your running app process.

The lightning bolt means Instant Run is enabled for your running app

Changed or added resources are also sent to the running app, with the affected Activity restarted to reflect those changes all within a few seconds.

Some code changes still require a full build (though the number of situations requiring a restart is shrinking as Instant Run evolves).

Instant Run works with all emulators (not just Google’s), and on almost every physical device — provided it’s running Ice Cream Sandwich or newer, which covers over 95% of active devices.

NOTE: If your dev device is running Gingerbread or Honeycomb, it might be time to consider investing in an upgrade.

Significantly Faster Full Builds

When you can’t use Instant Run, full build times are still more than two and half times faster, with Android Studio 2.0 improving each step of the full build and deploy process.

We’ve improved dx to use a quadratic algorithm to merge pre-dex’d files . It now also runs in process, and allows you to run up to 4 instances in parallel.

Typical DX times for “I/O Schedule 2015” App

That means we no longer start a new VM for each dx instance — giving the JIT more opportunity to optimize code, and removing the overhead of starting multiple parallel VM instances.

If your project has a lot of modules, you’ll see significant speed gains here.

If you’re using Proguard (which you should be), it creates a single JAR that effectively disables the advantages related to pre-dexing, so we’ve developed a new Shrinker for you to use in debug builds.

Typical “build and shrink” times for “I/O Schedule 2015” App

The Shrinker doesn’t replace Proguard — it replaces only the shrinking functionality — so you’ll still need to run Proguard on release builds to optimize and obfuscate your code.

When debugging, we now ask you to select a deploy target before your app is built. We’ll check what resources are required for that particular device and package and deploy only those resources.