Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Android Google Bug Cloud Open Source Operating Systems Programming Software Build Technology

Google Launches Android Studio 2.0 With Instant Run, Faster Android Emulator, and Cloud Test Lab (venturebeat.com) 58

An anonymous reader quotes a report from VentureBeat: Google today launched Android Studio 2.0, the latest version of its integrated development environment (IDE), with a long list of new features. You can download the new version for Windows, Mac, and Linux now directly from Android.com/SDK. In November, Google unveiled Android Studio 2.0, the second major version of its IDE. Version 2.0 brings a slew of improvements, including Instant Run, a faster Android emulator, and app indexing improvements. Google released a beta in February, though it didn't say when the final version would be ready ([VentureBeat] speculated in time for its I/O developer conference in May, and the company debuted with a month to spare). The full feature list includes Instant Run, Android Emulator, Cloud Test Lab, App Indexing, and GPU Debugger Preview.
This discussion has been archived. No new comments can be posted.

Google Launches Android Studio 2.0 With Instant Run, Faster Android Emulator, and Cloud Test Lab

Comments Filter:
  • The summary almost had the full feature list anyway. You could have edited all those links into it so you didn't have to repeat yourself.
  • by Anonymous Coward

    Queue the " it's better to use Vim/emacs (because it's light weight and real devs don't use IDEs)" developers

    • by jwymanm ( 627857 )
      It is better to use Vim/Emacs (Spacemacs ftw!). Real devs however use whatever works best for them.
      • by Tooke ( 1961582 )

        It is better to use Vim/Emacs (Spacemacs ftw!). Real devs however use whatever works best for them.

        Agreed. I use both actually. Android Studio is kept on one monitor. I use it for syntax checking, auto imports, refactoring, etc. I do the real coding in vim on the other monitor (with portrait orientation). It took some effort to get vim to auto-load changes made by android studio, but it works very well now. In the Before Time when Eclipse was the standard for Android dev, I used eclim [eclim.org] which eased the pain of Eclipse significantly. Thank goodness those days are over.

    • I can't get too enthusiastic about the 'lightweight' wars when I'm so spoiled by cheap hardware; but it is worth noting that, unless they've really fixed the hell out of it in this release; Android Studio is about as far from 'lightweight' as they come. Running it is like picking up a decent size chunk of tungsten: you expect it to be heavy; but just how much heavier than you had expected is still a bit of a shock.

      You'd think that an SSD, 32GB of RAM, and a 3.4GHz i5 would make starting an IDE containing
      • Sounds like they *still* haven't managed to get a true offline version working yet.

        Previous versions were horribly network dependent. Gradle would pull megs and megs of data whenever you started a new project (and at various other times). If you have a _fast_ network, it isn't too bad. If the end point is slow, or your ISP is typical American sloth service, expect to wait.

        The less bad news was that their *offline* switch (which is actually a cached switch) will minimize those occurrences (usually) *after

    • Agreed. I will put these developers in a queue, behind those that are interested in the current story.

      Bet those developers use xterm (or at best urxvt), because for some reason tabbed terminal emulators that use gtk2 | gtk3 | Qt for the right-click menu are evil.

  • by __aaclcg7560 ( 824291 ) on Thursday April 07, 2016 @08:05PM (#51864837)
    Two Google Android articles in one day. This is too much!
    • If I didn't know any better I'd assume they were building hype towards a new major release and a flagship Nexus phone in time for the Christmas gift buying period.

  • This version was released today and it is already one major revision behind Intellij IDEA. Why can't they track jetbrains head branch?
    • by Gr8Apes ( 679165 )
      Why can't they use a decent build system? Gradle is just about the worst option out there.
      • by brantondaveperson ( 1023687 ) on Thursday April 07, 2016 @10:38PM (#51865493) Homepage
        Dave's first rule of software engineering; All build systems are terrible, get used to it.
        • by AuMatar ( 183847 )

          All build systems get ignored. In a decade and a half I've never seen anyone just use a build system, they always end up writing their own around it (or in place of it).

          • by Gr8Apes ( 679165 )
            I've successfully used Ant in several very modular build environments where a module could be fully defined in as little as 2 lines. Unfortunately, I inherited both Maven and Gradle systems on other jobs, and those things are just a cluster to do anything reasonable with. When you spend more time modding the build system to support new code than coding, there's a serious problem with them. Gradle makes the case that Maven sucks. That's about the only thing the Gradle authors got correct. In every other way,
  • Let's see what VS can do to compete against it? Competition is wonderful and I am glad it's here. I do wonder if instant run is a good idea or will introduce more bugs?

  • I have a pretty damn capable computer. The android emulator is pretty much unusable. I will be very interested to see if faster translates to fast enough to actually use.

    In my present development setup, the only way I test on android is to test on an actual android. The only time I use the emulator is to see if it is going any faster.
    • Do you have HAXM installed? My experience indicate that full boot with HAXM installed is much, much faster than a regular boot on-device. Apps also run a lot faster in the emulator than on the device. The computer is a 2013 MBP, while the device is a Nexus 6.

    • What baffles me is how the Intel x86 atom-based emulator manages to be so sluggish. Assuming you have the correct alphabet-soup of Intel VT-D and VT-X and whatever else they are lasering off half their SKUs more or less at random today, even Intel's fairly tepid desktop parts will quite cheerfully emulate roughly as many guests as you have RAM for. Until you open up the emulator that only needs to emulate some feeble, power constrained, phone-SoC atom part.

      Then. Then you wait. A lot. This seems strange.
  • by loony ( 37622 ) on Thursday April 07, 2016 @11:51PM (#51865719)

    The emulator wasn't slow before if you picked a decent x86 image. Instant run only works in the smallest kinds of cases and any amount of time saved with it is wasted by fighting it when you know it won't work...

    The bigger question here is why does google spend time on toys like that rather than actually add stuff that people need? They are pushing material design - but you can't use cardview, recyclerview, and such in the UI designer and you're forced to go back to editing the UI by hand. Why do I have a UI then?

    Seriously - I know this is just bitching and probably the last thing that the people who worked hard on 2.0 need but this feels like adding cupholder to a car without breaks.

    Peter.

  • Couldn't they just say they've got incremental build support instead of using weird names no one knows of?

  • Am I alone in wondering what the heck this is about?
  • I was running Android studio 1.5 on an i3 with 4GB of RAM. Emulator load time was about 3 minutes, gradle builds were 1-3 minutes, time between gradle build finish and app launch was about a minute.

    After upgrading to 2.0, emulator load time is now 11 minutes, gradle builds are nearly five minutes and it takes nearly 3 minutes between gradle build finish and app launch.

"Gotcha, you snot-necked weenies!" -- Post Bros. Comics

Working...