Android Studio 2.0 Released | Hacker News Reader

Android Studio 2.0 Released

android-developers.blogspot.com

629 pointsingve96 comments

It's great that they improved Android emulator performance. Major frustration when developing Android apps is all the time spent waiting for the emulator or device deployment.

What always mystifies me about Android development is that there's no equivalent of the iPhone simulator (not emulator) of iOS development. I mean, Google has a perfectly fast Android runtime that allows you to run apps directly on your desktop at native speeds. It's currently built into Chrome OS, is already cross platform [0], and while it obviously doesn't give you to access some phone hardware features, it should be perfectly adequate for 90% of development scenarios. Why doesn't Google leverage that for click-and-run Android development?

[0]: https://github.com/vladikoff/chromeos-apk/blob/master/archon...

I may be totally wrong on this but I was under the impression that since Google started publishing x86 builds of Android the "emulator" is now much more like a simulator (unless you choose to run the ARM version, of course).

The thing that makes the emulator really slow is when it has to emulate ARM instructions on an x86, but if you pick an x86 arch then you're basically just running a VM, which should be comparable in perf to the iOS simulator.

Again, just guessing here, please correct me if I'm wrong.

Android apps still run quite slow on the x86 Android emulator. I suspect that this is because CPU emulation is only one part of full emulation of an Android system. When running Android apps using the Chrome runtime, apps run blazingly fast, since it just calls directly into the native OS / the Chrome runtime for any native acceleration feature it requires. It also doesn't run in a full-blown virtual machine as the emulator does.

As the other reply points out, the iOS emulator also doesn't emulate a full system. It just runs the required iOS APIs directly on OS X, just to give you an idea of a running app and the progress you're making on a feature. Again, for most development scenarios that is really all you need (and you use an actual device for more thorough testing or when you need hardware features).

The iOS simulator isn't an emulator, though. It's running the apps as regular, native process on the OS X host. There's no VM.

The perf difference isn't as major as between x86-on-x86 virtualization and arm-on-x86 full blown emulation, but the difference is still there.

Is virtualization cost that bad ? If the GPU drivers are good it should not be over 2-3x - which - when considering you are emulating mobile phone on a at least 2-3x more powerful hardware - should be perfectly acceptable.

ARM emulation is probably an order of magnitude slower

> I was under the impression that since Google started publishing x86 builds of Android the "emulator" is now much more like a simulator (unless you choose to run the ARM version, of course).

They're both still emulators. The difference is that when using x86 images, it now uses fast, hardware-accelerated virtualization under the right conditions (e.g. HAXM[1]) so it doesn't feel like there's a fat middle layer anymore.

Virtualization has come a long way in recent years, and the new emulator reflects that. Of course, there's still major hurdles when emulating different architectures, so ARM emulation is still a pain.

[1] https://software.intel.com/en-us/android/articles/intel-hard...

Yeah thats why ive found myself moving to AIDE in my remix os box runs the app right on the device but the mouse and keyboard make AIDE much more effective than using with my phone.

The new emulator runs ~3x faster than Android’s previous emulator, and with ADB enhancements you can now push apps and data 10x faster to the emulator than to a physical device.

About time. I don't know of any other aspect of Android development that gets as much hate as emulator perf (and I include Eclipse loathing when I say that). Though I'll say on latest with a recent MBP and SSD, the stock emulator isn't nearly as bad as it once was.

I am disappointed with a continuing lack of a decent test tools story. Whether UI automation or unit tests, I continue to run into "you need foo to get this to work, but the app's dependency on bar means you'll never get the two live in harmony". Espresso continues to look promising, but ramp up is still steep.

Espresso actually works reasonably well. Unfortunately it still has problem with handling timings and sometimes it just plainly doesn't find views that are clearly on screen and responding to touches.

Also it drags in 20k+ methods (whole guava!) which can cause severe problems since instrumentation APKs currently cannot be multidexed or proguarded with Gradle.

Does anyone know how that compares to the Xamarin Player? https://www.xamarin.com/android-player

use the visual studio one (doesn't need visual studio running to be used) or genymotion.

What? Visual Studio uses the emulator from the Android SDK, so I don't understand what you mean by use the Visual Studio one?

This is really exciting!

> Finally, the new emulator has rich new features to manage calls, battery, network, GPS, and more.

Interesting! I've long wanted more sensor/hardware feature availability in the emulator, so this is a good start.

I can't wait to try out the Cloud Test Lab integration. If it works well, that would be awesome (and futuristic). Still looking for official support for WiFi debugging.

All I've been waiting for is the damn thing to actually launch and run!

Would this mean that I no longer need to run Genymotion?

With the right architecture (x86, fast virtualization options on, Intel tools installed) GenyMotion is not faster than the current Android emulator so there's no advantage there. On top of that, with the 2.0 emulator, deploy speeds are much faster.

Personally I loved Genymotion and used it for all my emulator testing (although the vast majority of my testing was done on a real device). But with Android 2+, it's the opposite: 99% of my testing is done on the default emulator (the rest is using a device). It's that good.

With Genymotion you can run multiple emulators on a single machine. The Intel tools you mention (Intel HAXM for fast virtualisation) seems to work only for a single instance. The second instance does not benefit from fast virtualisation and is painfully slow.

Don't know whether this problem has been addressed by this 2.0 release.

A valid point. Haven't used it for bulk (automated?) testing, as I personally never find myself running more than once instance at a time while debugging.

Thank you for that feedback. I have been using Genymotion and its been a good tool to work with (no complaints). But being able to use the built-in emulator is simpler and easier when setting up other devs. :)

Supposedly. The new emulator runs at 3x plus you get all that Instant Run goodness that reduces build times.

You do if you need ARM. It looks like they just use x86 virtualization by default now.

Uhm, Genymotion never supported ARM.

Huh, it looks like they removed that. Back in like, 2013, that was their shtick, the ability to JIT ARM binaries in a primarily x86 environment.

Cloud Test is a great idea -- are they using virtual devices that exactly replicate physical device conditions? I guess they must, to accommodate (probably) thousands of developers simultaneously testing their apps.

Some of the apps I work on can only build on ARM, so the emulators were completely useless. Maybe it'll be better now!

Everytime I tried to switch to Android Studio from Eclipse I switched back because of how incredibly slow AS's build time is. Eclipse builds and deploys my app in seconds, AS takes at least half a minute. I tried all the tricks I can find on SO, etc. without success.

I find AS to be much faster, more solid and stable than Eclipse in every aspect. I've been using AS for a couple of years, and was on Eclipse for about 4 years before that.

With that said, your mileage may vary: Android Studio is one of those applications that seem to misbehave under certain specific conditions. Namely, if your main OS drive is not a SSD, things seem to slow down to a crawl.

Eclipse defaults to keeping all your tabs open, while AS defaults to aggressive LRU pruning? Eclipse always working hard to keep a live updated and as complete as possible bytecode model of your latest ctrl+s version available for instant (or close to instant) whole workspace error reporting, where AS only uses the compiler as a better linter, deferring non-local effects of code changes to the next gradle run, where errors are not even clickable in the console? The output of the IDE-internal "lint"-compiler run not even being available for a simple, local unit test rerun? Compared to the ambitious, smalltalk-derived vision of eclipse, AS sometimes feels like a glorified text editor that is only faster because it does not even try to do things eclipse does without much of a sweat.

Now for some perspective, i know i have a rather biased view in this: i came to AS from eclipse when switching from backend to android (still do my backend stuff in eclipse), so i am not tainted by the supposedly terrible quality of eclipse-based android tooling that came before AS. Also, i am highly suspect of subconsciously blaming the IDE for certain annoyances that actually are just extra stuff that any tooling would have to do for android dev. I never used full IntelliJ, so i am only talking about AS in the strictest sense and do assume that regular IntelliJ can be closer to eclipse in terms of direct compiler integration and even build tool builds will not only be much more flexible than the gradle guiderails in AS but also less heavyweight (i guess i'm only talking about the gradle android plugin in this part).

Now as AS2 claims to turn things upside down, i'd be glad to forget all this.

And $DEITY help you if you've fiddled with build.gradle. "Please wait five minutes while I go resync a bunch of stuff because you changed a variable name in your build file."

We use gradle at work with c++ projects. It's hilarious how slow it is. Why do people use it?

In a about a day of building with gradle, I could have manually downloaded and verified myself every jar my project will need, as compared to say, ant. The amount of time I lose to it is criminal especially considering it is supposed to improve our productivity.

Gradle is a horrible thing that lets people do whatever they want - and people who think freedom == productivity flock to it for that reason only. History of course teaches otherwise.

In my extremely biased opinion... because it lets you do terrible things in free-form code which opinionated tools like Maven don't allow.

(I'm not a fan)

Because it's faster than ANT.

(Used it via nVidia CodeWorks for Android when doing a mostly C++ project which also had some Java in it for Android.)

What's wrong with just using a makefile?

1) You're stepping outside of the boundaries of what every 3rd party API documents configuring ('add this to your gradle config') when I'm already too much of a bottleneck for figuring out build configuration.

2) You're replacing something that... mostly works out of the box, with something you have to configure entirely yourself.

3) Requires intimate knowledge of the entire Android build chain to properly set up. I might know about ~90% of it after some nasty debugging sessions involving flaky USB connections and commands which return 'successfull' exit codes / stdout spam when they fail - so we'll call the bus factor of that setup 0.9 as my coworkers frankly did not want to know, for which I don't even remotely blame them.

4) Yet another build dependency to install on every dev and build machine (make. *nix isn't an answer either: too many Windows specific toolchains for gamedev to make non-Windows remotely feasible as a primary dev environment.)

5) Not actually solving the remaining bottlenecks. Switching to Gradle got us down to ~5 seconds / build / project for the Java and APK packaging portion of the build, which looked mostly like it was dependency scanning, zipping, and code signing - just like I'd need my Makefile to be doing anyways. I was skeptical that I could do much better. Next, I switched linkers and saved closer to 90 seconds / build / project for even the simplest typo fix in the C++ side of things.

And that's just what's wrong with replacing gradle with a makefile. If we wanted to replace the entire build pipeline and build our C++ with makefiles too:

6) Would need to replace extensive existing MSBuild configurations entirely, or duplicate work between two different build setups. Would need to learn other platform build chains sufficiently as well (XB1, PS4, Win8 Apps... I don't recall seeing full docs on this when I still had access, although over the years I pieced together a distressingly large chunk of the pie. We'll optimistically call it 70% of the pie, for a bus factor of 0.7.)

8) Even with dependency files and substitution magic, make will rebuild more than VS with the right settings. I've also only ever done it with GCC - trying to figure out how to coax a proper dependency file out of MSVC's compiler doesn't sound fun. Mixing and matching compilers sounds like an even worse idea - a great way to introduce subtle rebuild bugs due to built-in #define differences. No, I'm not going to try and target XB1 with clang.

9) Poorer VS integration. Simple things like Ctrl+F7ing to compile / syntax check single files won't work without setting up your own keybindings to (ab)use e.g. "External Commands".

That might be most of what's wrong for my use cases.

This is a laughable generalization.

In response to a similarly laughable generalization, with added parentheticals explaining the rather specific case I found this to be true within.

I use gradle for Android projects.

We replaced ant with gradle when we switched to Android studio.

How to import a library with some resources with ant ? -copy paste it somewhere accessible in your project. It makes importing and more importantly updating the support lib (or most libs really) a pain in the ass.

How does it work with gradle ? compile "com.android.support:appcompat-v7:23.2"

Between this and flavors, I might not love gradle, but it is still a big step up from ant.

The first build is slow, but the later ones are faster as Android Studio use gardle daemon to speedup the build time

It's not just the first build, the later ones are slow for me as well. Eclipse's first build (e.g. after you do a Clean project) is also slow but after that it's very fast.

are you using wildcards (eg. com.foo:bar:1.3.+) in you deps in gradle? it forces gradle to look to the internet every time you build (unless you've checked "Work Offline")

Actually using dynamic versions (i.e. 1.3.+) are cached for 24 hours (unless you override the default). So you typically just pay the penalty for looking for new versions once a day.

I'll second that Android Studio has absurdly slow builds times. It's not pretty common to have 2+ minute build times, and I'm using a MBPr mid 2015. I actually asked an Android frameworks engineer about this, and it seems like this is not an uncommon problem.

The instant run in AS2 helps a lot, but without it, build times are unbearable.

Exactly this. Even "Instant Run" has often been slower for me than an Eclipse run. Since I don't have a Core i7 with 16Gb of RAM, I stick with Eclipse for Android dev. I'm using Andmore (fork of Google's deprecated ADT plugin). I still use Gradle for the build configuration, but using the Gradle Eclipse AAR plugin (https://github.com/ksoichiro/gradle-eclipse-aar-plugin) I can simply edit the build.gradle file, run "gradle generateEclipseDependencies", and then import the generated Eclipse projects. Bonus being that I can "gradle assembleRelease" my app.

How does this compare to running Android in VirtualBox via osboxes.com? I pretty much have to do this in order to make my setup work (unless I want to use my phone for testing).

I have ArangoDB running in VirtualBox to provide backend data. If I try to run the emulator, I can't because VirtualBox and the emulator don't play well. The only think I've found to get the emulator to work is to use an ARM version of the emulator, which makes it hard to use.

An all VirtualBox setup works fine. I'm not sure how to make the emulator phone like rather than tablet. Other than that, I'm ok.

I've seen some venting in the comments here about Gradle and general build times. So I thought I would mention Buck[0] as an alternative build system. Vine as a great article up about how they sped up their build when switching from Gradle to Buck[1] - a large part of that was due to Buck's exopackage[2] feature.

For the curious, Google has a system like Buck - Bazel[3]. From what I know it served as the inspiration for Buck, but I could be wrong.

[0] https://buckbuild.com/

[1] http://engineering.vine.co/post/117873038742/reducing-build-...

[2] https://buckbuild.com/article/exopackage.html

[3] http://bazel.io/

As I understand it, some xooglers missed blaze/bazel so much that they built copies in their new companies -> bucks & pants.

How fast is the new emulator compared to Genymotion[1]? Is intel HAXM still required?

[1] https://www.genymotion.com/

Not sure about the speed compared to Genymotion. HAXM is still required but less buggy now.

> IntelliJ 15

That is not the most recent release of IntelliJ so it's at least one version behind. I should also note that IntelliJ has abandoned the version number name, the newest versions of the IntelliJ IDEs have the year now. The most recent IntelliJ IDEA is IntelliJ IDEA 2016.

That such a widely use fork of IntelliJ is behind a version is important for plugin developers who will be held back from adopting new features if they want to support Android Studio.

I think IntelliJ 15 shipped with its own JRE so it may be possible to write plugins in Java 8 instead of Java 6 for Android Studio though, so if that's true that's nice.

IntelliJ 15 was released in Nov, so we're talking 6 months. What features of IDEA 2016.1 do you need for creating an Android application that aren't present in AS 2.0? I use both frequently and it's hard for me to feel behind (so far).

If you're interested in keeping up-to-date, Android Studio also has Chrome-style Canary/Beta/Dev channels as well.

I don't have a feature that immediately comes to mind but I've run into it before when developing a plugin for intellij. It's just something to keep in mind. I don't understand why there's a separate IDE at all, why don't they just make Android Studio and IntelliJ plugin and leave it at that. Then there would be no issue. You can do so much with a plugin. There's really not much you can't change in the UI with a plugin.

> why don't they just make Android Studio and IntelliJ plugin and leave it at that

Because they make changes to the core. HN recently linked to a JetBrains thread where a blind user opened a usability bug regarding using screen readers in IntelliJ[1]: a significant portion of the code to address that came from a Google Engineer working on Android Studio and merged upstream into IntelliJ.

1. On mobile, can't get the link right now

Do you mean this? https://code.google.com/p/android/issues/detail?id=82716

I love IntelliJ, but it makes a lot of sense for Google to make their own branded IDE for Android development. Android applications are written in Java, but they also have a specific structure and conventions, build and deploy stories, distinct debugging and sdks, etc. Not to mention Google can build great Android layout editors, lint checkers, and other integrations such as the 2.0 flagship feature, Instant Run.

Yes, of course you can build Android with standard IntelliJ, but for making Android development more accessible AS is a great direction. Trying to get the old Ant + Eclipse + random tools in the sdk work together was very challenging, and - at least thus far - AS has been tracking IntelliJ pretty closely so I don't feel out of place. Not to mention IntelliJ doesn't have to be tied to the (very large) community of Android developers; Jetbrains can continue building their product to be more of a neutral all-around (fantastic) development environment.

Android Studio contains C++ (NDK) support, which is not available in the Idea community edition or other free product. Only in Clion (paid). Having it as a plugin could cannibalize this product.

I cannot speak for Clion, but Android Studio it is still a pain to use for NDK projects, when compared with VS 2015 support.

Could you be more specific, what are pain points in AS compared to VS2015 when working with NDK?

- Gradle support for NDK is still work in progress and keeps changing

- Android Studio doesn't support ndk-build based projects

- Android Studio turns my core duo, with 8GB RAM, 512 GB HD into a propeller airplane and Gradle builds take minutes versus seconds in Visual Studio (Ant/ndk-build)

- VS2015 has direct support for mobile cross platform, so I can from the same IDE target Android and WP

- Intelisense is faster and more accurate on Visual Studio than Android Studio

- I am yet to test the debugging support, including visualizers in Android Studio, because I lost my patience to keep on waiting minutes even for "hello world" builds

- Visual Studio C++ team tries to improve the experience and actively asks for feedback, Android Studio team just ignores NDK users.

> I think IntelliJ 15 shipped with its own JRE so it may be possible to write plugins in Java 8 instead of Java 6 for Android Studio though, so if that's true that's nice.

On Linux, IntelliJ 2016.1 is still shipping with its own JRE (I don't know if they used to do this before) and that is very important for this release since they modified it so that the fonts don't look like shit anymore.

I wonder, is there any reason to use Android Studio over IntelliJ for android development?

> I wonder, is there any reason to use Android Studio over IntelliJ for android development?

NDK development would be a good reason. IntelliJ doesn't have free C++ support/plugin, does it?

And not all features available in AS are available as IntelliJ plugins either.

VS 2015 NDK support is still better than what Google is able to provide for their own OS.

1. This is a side point, not relevant to the original point about IntelliJ not being good enough to replace Android Studio 2. VS 2015 doesn't run on my system. Both IntelliJ and Android Studio do.

Thanks. That one would be a very good reason but, at least for now, not something I need. Moving from intelliJ to android studio should be relatively seamless, I assume.

For those getting lost in the IDE I recommend trying command line. Here's a good tutorial: http://geosoft.no/development/android.html (you'll have to change some file paths due to SDK path changes though, just search for the executable)

I find Android development very tedious though (compared to web-dev) both with and without the IDE. Especially the xml-files and "enterprise" Java code.

This is really outdated IMO. Why not just build using latest and greatest with gradle?

Change is hard.

I use a bash script.

Using gradle, especially with how it integrates with Android Studio, is a much better solution. Google really got it right with gradle IMO, in that building from the IDE builds EXACTLY the same as if it were built from the command line with gradle. Building manually with bash like this just seems masochistic.

What's with the handholding when downloading? I'm trying to download the Linux version on a Windows machine and it keeps trying to force the Windows version down my throat... spoofing my user-agent fixed it.

Just scroll down:

http://developer.android.com/sdk/index.html#downloads

Oh sure I could do that. I could also fix the vacuum by plugging it in. (Dammit. I was not on a FHD screen and that isn't the first time I've made an above the fold mistake like that.)

AFAIK they used modified version of QEMU to run Android. Will the speed enhance take any effect on the base QEMU? Or there were just OS optimizations?

OS X: just wanted to start my 3 weeks old Android Studio to update and realized it wants Java 6 from Apple. Is this normal? I have Java 8 installed here.

Apple's Java 6 uses Quartz for text rendering, which looks really good and is pretty fast. Oracle's Java 7/8 do text rendering in software, which is slow and looks extremely bad on OS X compared to, well, everything else.

It only uses Java 6 for the IDE, Gradle and the other Android tools should still run with your regular modern Java 8 if I'm not mistaken.

It's not ideal, but after comparing the two I found Java 6 + Quartz by far the best solution for now...

Did you try the openjdk that is bundled with intellij idea eap builds? It is Java 1.8 with quartz font rendering. I use this version since December last year to run AS without any problems.

thanks for the long explanation!

I am been using the 2.1 canary (beta) version for a long while that i didn't noticed about the new version.

However, in sum, using a emulator is still a bad idea.

How feasible would it be to run your own virtual Android device on a VM and access it remotely like VNC or rdesktop? This could be nice for running clients like WhatsApp or Snapchat and accessing them from a real computer with less privacy worries to boot.

(Yes I know there are per app ways you can often archieve this if you tinker around enough, not the point)

Glad to hear emulator performance has improved so drastically. Did the Android team take the time to tackle the, what, 5 year old bug that prevents retina computers from seeing the screen clearly yet? Kinda of a huge pain in the ass and makes me groan whenever I have to start the emulator and test my Android apps.

Update: Yes they did! Wow, what an improvement!

We've used the beta releases for a few small class projects already with good results. No major issues.

I was very excited for the improved emulator, but I also run Docker to simulate my app server, and the Android emulator does not run simultaneously with VirtualBox. Sticking to GenyMotion I guess...

Does this support 32 bit linux?

Why do you want 32bit linux support?

(not hating, just curious)

I'm using ubuntu LTS, 32 bit is working good for me, only google chrome and newest Android SDK is missing. I will switch to 64 bit when the next LTS is released.

Sorry, just curious - doesn't 14.04 LTS have a 64-bit version? I think I ran it for a while (I don't always stick to LTS though).

Yes of course

My computer from 2009 is limited to 32-bit but it's still working fine so I'm reluctant to throw it away. I guess I'll have to now.

any word on how 'warm swapping' compares to buck build?

Not sure if there's any good 'official' link, but: it depends on what you need to replace (adding methods? changing methods? changing resources?).

In 90% of the cases it's much faster, maybe by cutting build+deploy time by 90%, just because you don't have to rerun the app.

In 5% of the cases it's a bit more involved but still faster.

In 5% of the cases it fails miserably and you spend 200% more time just stopping everything, doing a clean build, and deploying it again just to be sure.

Did you actually mean Windows Millennium Edition, or was that a typo?

Man, I just grabbed Studio today to install on my new MBP, and I was baffled to see it had completely changed from the version I had installed on my old one like...two days before?

Way to surprise me.

The "stable" versions take a while to be released. The previous stable, 1.5, was released in November 2015. The new one, 2.0, was released today.

For some people it may make sense to use the Beta, Dev, or Canary versions instead. Those, of course, have much more frequent updates (some near daily).

Did you see the compile to iOS plugin, thats so cool! OK just kidding. But seriously waiting for it.

Reply on news.ycombinator.com