Hacker News new | past | comments | ask | show | jobs | submit login
Android Studio 3.0 Release Notes (android.com)
271 points by satysin on Oct 26, 2017 | hide | past | web | favorite | 148 comments

This is a side note, but most members of the Android team at Google used to have 256 GB of RAM on their computers to compile Android (the entire build). When we used Android Studio, it was blazing fast so most devs that didn't work with users were not aware there was a problem.

I'm on the Android team and no, we don't. The current spec workstations are 128GB RAM, 1TB SSD, and 2x Xeon E5-2690 v4. But there's still a lot of the older 64GB & 96GB workstations in use as well.

The low clock speed of the Xeons (plus NUMA) means that for most things the machine isn't actually that fast, though, unless you can put the all the cores to use.

I don't think that really refutes the point, the median public user of Android Studio is probably closer to 16GB of ram right? With a nontrivial percentage of people with 8GB? So you're still talking about an order of magnitude more ram than those people.

Median 16GB? No way from my experience with dev agencies - most are on 8GB, some on 16GB, some on 4GB. I think I've only seen one Android dev with 32GB, ever.

Correct. There's a lot of Android devs from south asian countries (India, Pakistan) too which tend to use cheap machine with 4-8 gigs of RAM.

Quite a few of us run Android Studio on 16GB laptops as well and it works fine there, too. It doesn't seem to be particularly RAM hungry.

I’ve never used a machine with more than 32 gb of ram. I suspect if one did a survey the average android app developer is on an 8 gb dual core laptop.

Wow, I thought 256GB was a typo.

I don't think I've ever used a machine with more than 32GB.

Really?!? No wonder that Android Studio is so sluggish when compared with the former Eclipse tooling.

In many parts of the world having access to a 8 GB and SSD drives is still considered a luxury.

I wasn't on the Android development team but rather I was in management, but my colleague was and that's the information I got when I tried using his workstation (he specifically works on Android framework). I actually never checked myself so that's my mistake, so I apologize if I am spreading misinformation.

Funny you mention these stats, I work on Solvent IDE (codesolvent.com), I purposefully avoided beefing up my dev laptop to keep me honest...my dev box has crappy performance so that when I run the software on a more capable machine (like a medium ec2 instance) I get a nice performance boost :)

Always better to be more conservative to get a better sense of end user experience.

Not sure where you get this from, I'm not in an Android team, but from what I can see the top offered workstation one can get at Google has 64 GB of RAM.

I would assume that there was a special policy in place for people working on teams with a requirement for that amount of RAM.

I interned on Chrome in 2013, and at the time all Chrome engineers got a computer with an SSD (which I was told wasn't standard at the time), since they had to build Chrome on their desktops (whereas most other engineers could use Google's distributed build system).

The Android team used to get access to higher specced machines than the standard engineer, because building Android in its entirety took a long time.

At the time you could see them on stuff but could only apply if on one of the approved teams. Not sure if that's still the case.

64 seems a bit low, that's what I need for my hobbyist work. Granted, it doesn't take 64GiB of directly-allocated RAM to link Chrome (anymore), but there's almost no amount of page cache that would not be worthwhile if you have the whole AOSP on a box.

What kind of hobbies do you have? Lol

Yeah, even on 16G it's a dog.

Once I find a good replacement for jump-to-usage in VSCode I'll probably ditch it for good.

It runs very well on my 16GB RAM. I find a lot of the speed is in internet and hard drive speed. It opens up a full project in 3 seconds with a SSD, assuming there aren't too many dependencies.

I was also forced to buy an SSD to make my life easier, but lets be honest, SSDs are still quite expensive on price per GB on first world countries, let alone the rest of the globe.

Same regarding RAM, I know of companies that a standard developer machine is 8 GB, while everyone else gets 4 GB.

Getting something like 16 GB is unthinkable unless that is a business related change request.

So basically making the life miserable for those developers.

you're right - SSD makes a big difference too.

Try it with something non-trivial. SSD here as well, the difference between Android Studio and VSCode is night and day.

I dont think you could rightly compare the two. One is a full IDE the other isn't.

Visual Studio (not code) is the most smooth actual-IDE I've used, by a wide margin.

The whole damn thing just uses only one thread for UI, how is that smooth?

Mostly in context of text editing/auto completion hints. With e.g. intellij there's enough choppiness/delay in typing and completion to really put me off.

Have you tried the new versions with Zero Latency Typing? As the name implies, they managed to basically eliminate all latency on typing, even beating apps like notepad++ and emacs on latency. It's switched on by default in the current release.


Was that before or after Visual Studio became a bloated pig?

I use VSCode as a full-blown IDE for Rust(including jump to def) and it works great for that.

Jump to def is like the minimum thing of a IDE

Well, there's also a debugger, source control, syntax highlighting and intellisense.

Looks like an IDE to me.

Pretty primitive compared to what IntelliJ actually does, which for Java (and typed JS, Scala, Kotlin, etc) is full source code indexing and understanding of the type hierarchy.

That means "Find Usages", "Jump to Implementors/Overriders", "Show Substypes", etc all work correctly. When you ask for code completion, it's far above what IntelliSense does. IntelliJ will actually understand all of the variables and types that are reachable in scope, as well as those that are reachable by calling methods or accessing fields on those types two or three levels down. This is not the same as just examining what's reachable via 'this' or what's to the left of the '.' character.


The autocompletions are also ranked and sorted properly most of the time. Think of it as the difference between a shitty search engine and one that shows the most probable autocompletions first. Even Eclipse IMHO is pretty bad at this, and will often try to suggest meaningless classes somewhere on my classpath that I'm obviously not going to use, including internal sun.* implementations.

IntelliJ's refactoring and code analysis is also far above what XCode and VSC do. I've been using IntelliJ since the first version, and to me XCode and VSC aren't much of a step above Emacs as an IDE.

Syntax Highlighting, VCS integration, Debugger, and Jump to Symbol Definition are table stakes that even basic text editors have.

Erm, VSCode does all of that for Rust via RLS and the Language Server Protocol[1]. Heck, VSCode does even better than Android Studio because the pick common words in the source file as part of their auto completion. Things like comments, untyped parameters(ints, etc) all work much better in VSCode.

I'll agree that for Java VSCode isn't up to par yet but for many other languages it's easily at an equal level.

[1] https://github.com/Microsoft/language-server-protocol

VS code gets full intellisense for e.g. C# (omnisharp), and many of the implemented language servers do real-deal source code indexing.

https://github.com/rust-lang-nursery/rls for rust

This is a matter of opinion, but language-specific navigation, searching, and refactoring is where I'd draw the line between an editor an an IDE. VS Code may not be there yet, but they're improving quickly and I think it's only a matter of time.

Better search ranking seems like a feature that could easily be added (though it has to be done for each language).

I'm happy to see competition in this space. The end user might not see it, but IntelliJ internals are pretty horrible from a plugin developer's point of view and haven't improved in many years. Moving language smarts to editor-independent servers (with VS Code's Language Server Protocol) seems like the right architectural move.

While I agree that IJ's internals are spaghetti, the VS LSP isn't quite the same, or at least, it appears to me, it does not offer the richness of IJ.

Consider that IntelliJ can syntax color and autocomplete multiple language grammars at once, e.g.

String aJavaString = "<someHtml onFoo='someJs.style=\"color: red\"; var regex = new Regex(\"someRegex\");'">

Does VS's language server protocol handle the ability to deal with nested language grammars each with nested contexts?

My issue is false negatives: IntelliJ usually just "works", especially with Java, it's near perfection and almost never gives a wrong completion. I've never encountered another IDE whose code understanding was as complete. Even a 2-3% false completion rate is super annoying.

Plus, the refactoring, structural search, and callstack analysis stuff is beyond reproach. Can VS tell me all possible reaching expressions to a given method? I've used that before to figure out what kinds of subtypes or nullability a given parameter has, but it requires global code understanding.

I feel like the kind of functionality that grok style code indexing provides is just the baseline, and what's important is what's built on top of it. VSC has a long way to go to reach IJ in that regard.

Looks like they just added nested languages in the latest version: https://code.visualstudio.com/updates/v1_17#_language-suppor...

While agree that IntelliJ is pretty great the Android Studio implementation of it is nowhere near perfect. I've had false lints, incorrect flags and a whole class of issues where intellisense goes wrong.

I love Intellij but Android Studio so far was a complete constant disaster.

Obscure build errors, very slow builds, all kinds of device connection failures, gradle wtfs, (un)necessary manual config edits .....

You pretty much just listed gradle 4 times.

Except, Gradle 4.1 with kotlin scripts (unless android studio overwrites your gradle version AGAIN) works fine nowadays.

But Android Studio actually managed to break builds on non-US locales because they used String.format using the system locale (which means %02.f renders with a ,)

Isn't this true of mostly any dev environment? You'll run into one or more of those every once in a while. Colleagues running XCode for iOS development think it and Swift are a piece of crap too most of the time (though the latest rewrite for iOS 11 apparently was a big improvement).

I've ran this version for going on 3 months now and pretty happy. I've run into some issues with Kotlin builds and preprocessors (can't see the build errors in the Gradle console, have to run a command line build with --debug flag) and every once in a while the emulator and IDE stop talking with each other (ADB needs a reset every so often).

> Isn't this true of mostly any dev environment?

C# + Visual Studio, the build will just work. The fact that editing the MSBuild XML is not really necessary for 90% of developers helps with this a lot.

You're probably right for modern/default use cases, but I've seen C++ for Windows Mobile fail terribly too (Android Studio supports NDK/Native C++ code also).

I feel this is less on Jetbrain's IDE and more on the Android environment.

Session 'app': Error Launching activity

not much has changed :(

I know, the above bug can be circumvented by unchecking "Instant Run"

Installation failed with message Failed to install all .

That's enough for today

OK, just one more:

Error while uploading slice_4.apk : java.lang.UnsatisfiedLinkError: No implementation found for java.lang.String android.os.SystemProperties.native_get(java.lang.String)

This series perfectly sums up my experience with Android Studio. IntelliJ itself, on the other hand, works every time.

I always wonder how they actually test it.

Last RC did not even update on Macs.

"Error Launching activity" depends a lot on the device. For example it happens a lot for me on a Moto G3 but rarely on HTC.

Are slow builds AS-specific? I think it's more related to the Android build ecosystem and not the IDE.

After my experience with Android Studio I started to enjoy using Eclipse again.

The migration experience was even worse for those of us using the NDK.

Three reboots for the build system, no migration path until CLion was developed, debugging features only available to Java code,...

Although they have made major improvements, I always ask myself if they had spent all that money improving the Eclipse based IDE, how much better the overall experience would be.

This is what the android build system has been like since way before Android Studio - there are always incompatibilities between versions.

It has nothing to do with JetBrains. You won't find it on their website

The core of Android Studio is IntelliJ.

Kotlin to rescue! Shameless plug https://hackernoon.com/in-pursuit-of-better-jvm-futures-kotl... I have seen/followed Kotlin since it's early days and I was so sure it's going to be next big thing for Android. After failure of Scala we had no other options :P

For people that don't actually use Android Studio, what does your dev setup looks like?

React native! Sublime to edit text (mostly the React app, but you can modify Android/ios if you want). I have the node CLI compiling code in one terminal, and then pointing all that to a Genymotion android emulator. Pretty smooth! Not having to compile the whole android app that only serves as a container to the JS is a godsend!

http://flutter.io works right with IntelliJ IDEA, so you don't need to deal with the Android SDK junk.

even flutter doesn't use studio's gradle setup.

I'm not sure what you mean by "setup" but Flutter does use Gradle and Flutter's Gradle plugin [1] depends on the Android SDK's Gradle plugin.

Also, Flutter's install instructions say: "Flutter requires Android Studio to be installed and configured" [2].

The Flutter SDK hides this away nicely, but Gradle runs when you launch a Flutter app during development (on Android).

[1] https://github.com/flutter/flutter/blob/master/packages/flut...

[2] https://flutter.io/setup-macos/#android-setup

You definitely can build Flutter apps for Android without Android Studio. https://ifdevthentalk.com/2017/05/29/flutter-on-windows-with...

Flutter instructions only say that because google is shifting from providing just the SDK.

First there were SDK and NDK links.

Then there where SDK Tools that autoupdate and downloads the SDK.

Now there is only links to studio, an IDE that contains the auto update tools that downloads the SDK.

But if you want to jump all the hops, you might be able to download just the SDK. For now some old convenient links might still be up.

You can do Flutter dev without Android Studio[0], but I'm guessing if you want to ship/test in the world of Android, you would need Android Studio.

[0] https://flutter.io/intellij-ide/

Yes, Android Studio is needed for running Flutter apps on Android but not for iOS. (You don't normally need to launch Android Studio, just have it installed on your machine.)

Similarly, if you want to run on iOS you need a Mac with xCode installed.

(It's rather weird to me that you need to install entire other IDE's as developer dependencies to build mobile apps, but that seems to be how it is.)

> It's rather weird to me that you need to install entire other IDE's as developer dependencies to build mobile apps, but that seems to be how it is.

I don't remember the details, but a couple years ago there was a way to install just the Xcode build tools without installing the entire IDE. I'm sure there's a similar process for the Android SDK. (Though, of course, none of that is officially supported, so you're on your own for the most part.)

Edit: Turns out Google provides downloads for just the SDK without Android Studio[1], so it looks like the separation is unofficial only for Xcode.

I do Android dev in Visual Studio with Xamarin.

Your app is structured the same as a native one (Activities, Receivers, Services, Layouts, etc) and the XML for your layouts is identical, but you get to work in C# and don’t have to deal with Gradle etc.

I like it.

What downsides does it have compared to a more traditional environment? I'm a C# developer so Xamarin sounds really tempting, it's just that I don't want to break my head on "simple" stuff I could easily avoid with a traditional environment

You still have to learn the underlying story platform and API, that’s not abstracted. Also choosing between Xamarin Forms and Xamarin Native for the UI (not compatible between them). Obscure errors sometimes.

But from my (little) experience on it, getting to an app running and start working on it is way mire easy than with the Java approach. Give it a try :)

Maybe the designer isnt that good.

But overall it's much better. And you get:

Shared models with your web api, reusable business for iOS and Windows, great tools like ReSharper, and so on.

I am currently using a pure command-line build, with Ninja build files, and a standalone NDK toolchain (https://developer.android.com/ndk/guides/standalone_toolchai...). It's a pretty hacky solution but it works and it's very fast.

This is for C++ code, which is kind of a special case. Android Studio now has C++ support but I tried it and wasn't impressed. Among other problems, the build process seems to be extremely slow.

We are pretty much 2nd class citzens on AS.

In the early years of Android Studio, I generally preferred IntelliJ. I have since converted our application and main library (SQLCipher for Android) to use Gradle. I have Instant Run disabled, but otherwise I haven't run into many issues with Android Studio. We still coordinate our library build with a Makefile.

Cordova in Visual Studio right now.

(On very lean teams that don't have the resources to build bespoke UI for every platform, even with Xamarin or React Native, and the web platform is a good compromise for the simple data collection apps we are building.)

Same here. Using Cordova with Atom or Sublime, and building/signing/deploying on the device via the CLI.

We need to deploy to desktop/mobile/chromebook and we don't have the budget to develop native UI for each one.

The be honest the only problematic platform has been iOS and its crappy UIWebView / WkWebView, and Windows but only because we are using Squirrel for the installs.

What's wrong with Squirrel and Windows? I thought they had a Windows update framework?

It has given me a few headaches. On Mac, Squirrel has worked flawlessly.

The biggest headache for my users is that the app is not added to the start menu, and the .exe is buried in some deep bizarre folder. Maybe there is a way to solve this, but I haven't been able to find it. There is an option to add a shortcut to the desktop, but if the user deletes it then the exe is lost forever.

I've had other bizarre problems for a few users and the only solution was to reinstall the app from scratch. Tech support is not very happy about that.

Maybe it all stems from my Windows ignorance but Electron-builder, one of the most important projects for packaging Electron apps, is moving away from Electron to NSIS. The problem is that AFAIK NSIS doesn't work with Electron updater.

I'm seriously considering moving away from Electron and replacing it with a UWP JS app and distribute it via the Windows Store.

VSCode dropped Squirrel on Windows ages ago for most of those same reason.

My only reason to support an Electron app on Windows is a need to import ancient Access MDB files. I've been meaning to explore deeper the possibility of using the desktop bridge for my Access reader component and call it from the Cordova UWP JS app. It's on my TODO list to explore, but I think just having a single UWP app (with a desktop component that lights up as available) would be the best distribution plan on Windows.

Do you know what VSCode uses now?

Man, that sucks. I just read through the discussion on that and can see where the pain points are in using Squirrel.Windows [0]. Hopefully they eventually deal with that. I don't use Windows much, so outside of making sure Squirrel.Windows is working correctly, I don't have much of an opinion on whether or not it provides a good UX to end-users (and it sounds like it doesn't, unfortunately).

[0]: https://github.com/electron-userland/electron-builder/issues...

I'm about 75% vim, 25% Android Studio, usually in that order (bulk of the changes in vim, then cleanup in studio).

Is this effective? I've never used vim, but Android Studio is great as an IDE. It has lots of autocomplete for tedious things like layouts, the shortcuts open up files as needed, and it highlights more effective ways to do things. This is extra useful for Kotlin.

I use Qt Creator with Qt 5.9 for C++/QML/Js programming.

I use IntelliJ, with LibGDX/Gradle (game development)

Last year: Ionic/Cordova and Visual Studio Pro.

This year: Expo/React-Native and VS Code.

you can't.

in typical Google being evil fashion, using their central authority on Android they now discontinued android sdk and made the sdk a piece of android studio. for no reason other than forcing everyone to beta test their "version 3" (ha) studio. so much so that you now have to download the whole studio, and pick the sdk from within it. there are still some ways to find the sdk directly, but they are going away.

I'm not aware of plans to force users to download sdk only through Android Studio. You can find download links to the sdk at the bottom of: https://developer.android.com/studio/index.html

disclosure: I work on the Android Studio team.

Egg, meet face.

Yes, but now it's CLI only. It used to have GUI.

Not saying it is forbidden. But everywhere that google used to say "download the android SDK" now says, for no good reason, "download Android Studio".

Why does flutter tells to download android studio, open it, run the sdk downloader, close it forever and move to another IDE?

Kotlin and Swift are godsends to the mobile development world. I am a happy programmer because of that. Kudos to Google and Apple.

JetBrains, not Google

Well, for writing Kotlin. But Google chose to implement it officially.

They said they will support it officially, which means they are in conversations with JetBrains to make it stable in Android Studio. They didn't implement a thing in the language, not even the plugins for android studio.

A lot of developers were already using kotlin before google announced anything.

But it still helps that they endorse it.

Anybody know if the Scala integration is useful in this release? Apparently the last version wasn't that far off[1]. Has it gotten better or worse?

[1] http://scala-on-android.taig.io/editor/android-studio/

Kotlin was the worst thing that happened to Android, I mean no disrespect but it seems that JetBrains and its team are really trying very hard to shove Kotlin down people's throat, the sad thing is that despite knowing the fact that it doesn't offer any performance improvements over Java, it is being paraded as the next big thing by overtly excited enthusiasts.

As a user of Android and a developer I want something that enhances the user experience of the apps I use and I create, I want the apps to feel and behave as smooth as iOS, the team at Google should focus on that and not on fragmenting the already fragmented community, right now they are solving a problem that doesn't exist.

I wonder if I would ever see 120/240 FPS apps in the future or if I could offload UI work and animations to a different core because you know your 7 cores are sitting idle and you can do nothing about it.

As as developer I am totally happy that it increases my productivity. You know, you don't have to use it? It is not shoved down your throat. It is a supported offer.

For what it's worth Android has used a separate thread for rendering since API 21. When you implement onDraw, it's really recording the commands and then sending them to the render thread for actual execution.

It doesn't fragment the community as you can call kotlin code from java and vice versa. Seamlessly.

Kotlin is great in that it brings Java 8 features to Java 6(lambda expressions, functional programming, etc.) and more. It's a boon to productivity and makes programming in the Java ecosystem fun again.

There is a sometimes increase in compiling speed but it's very marginal and the method counts increase with the transpiling but it's not noticable until the app get's on the larger side.

Does this noticeably improve build times and general smoothness? Because that's been the major problem with Android Studio.

For big mostly-C++ projects, it's considerably smoother than 2.3. It's still pretty slow to open and "gradle sync".

Yes, this was a major focus for the new Android Gradle Plugin. Unfortunately, this did mean breaking their Gradle DSL (part of reason for the new 3.0 version). Here's a talk discussing the changes:


>noticeably improve build times

yes, the newish build model is modular, allowing to only compile what needs to. Still not perfect but a huge improvement.

>general smoothness

Just as before, give enough ram to AS. Generally if it is slow it is because it is constantly trashing the memory.

Trashing memory, or thrashing? Because with AS, I’ll believe either.

thrashing, english is not my first language ^^

Hmm; I have been running extremely large projects on AS with a good but not out of this world machine.

Compilation times are too slow for my taste (ie even clean should take less than 5 seconds ideally), but the IDE itself is pretty smooth.

Again, the trick is to monitor its memory usage. It is a pity that it's up to the user to configure this, but for large projects I had to allocate more memory to AS and it makes it go from unusable to lag free.

thrashing, english is not my first language ^^

No, no, your English is fine, it's AS that's the problem. :-) I assumed that it was probably a typo of some sort, but I would truly have believed either usage. Though AS has gotten better about not trashing memory.

That said, I agree that with a properly provisioned machine, AS does well. And it's a vast improvement over its predecessor.

Yes, the new Gradle plugin reworks how dependecies are handled (significantly improving compile times for larger modular apps) and has quite a few improvements in configuration and resource processing performance. Instant run has apparently been rewritten as well.

Unfortunately those changes do mean a few breaking changes for build.gradle files.

If most of my build.gradle files need to be tweaked in order to work with AS 3.0, then I might as well just rewrite them in Kotlin -- after all, they're only 30 lines long. That way, I can use Kotlin as my programming language for Android and my build scripting language.

I don't think it does too much but it improves on the instant run feature which does indeed make a huge difference but at times is still dodgy

The big feature is their new profiler. Have you tried it? What do you think?

Only played with it a bit so far but it seems to me that the call and flame charts are now missing any timing information. Unless I've overlooked it you can't actually see how long a function takes to execute - defeats the purpose of instrumented profiling surely!

Instrumented trace capture modifies the execution profile too much for timing information to be useful, and then sampling profiling which doesn't modify the execution profile doesn't have timing by its nature.

So if you were using the timing data previously you were basically just looking at random numbers that would send you on wild chases into things that weren't real. The new one fixes that by not showing bogus data :)

That's not a fair comment and you know it.

Yes, instrumentation adds overhead. The absolute numbers cannot be used to determine peak performance but that's never the intention when profiling code.

Instrumentation rarely modifies the execution profile to the point that the numbers are 'worthless' or 'random'. My rule of thumb is that self times near the leaves of the callgraph are more accurate than self times further up the graph but having some indication of timing is important.

Furthermore with something like the call chart in AS3 you are often looking for outliers that you can't see when looking at an aggregated view of the profile. A function that has an average of 1000us might be running alternately at 500us and 1500us and you want to see that. It may indicate an unknown performance bottleneck, maybe a call to OpenGL is causing a GPU sync for some reason. It's rare that the instrumentation overhead would dominate major effects like that. Having a number available is important for this as you may be comparing invocations/looking at different parts of the graph at different zoom levels etc. Having a number available is the only solution.

Furthermore, where do you think the instrumented profiler is getting numbers from in the aggregated views? Answer: exactly the same place that the callchart gets it's numbers from. In essence you are saying all instrumented profilers are inaccurate and reporting bogus numbers, demonstrably untrue.

> Instrumentation rarely modifies the execution profile to the point that the numbers are 'worthless' or 'random'. My rule of thumb is that self times near the leaves of the callgraph are more accurate than self times further up the graph but having some indication of timing is important.

I was only talking about the instrumentation system on Android, not the one anywhere else. It forced ART to fall back to interpreted mode, so no JIT at all, which massively balloons the cost of certain things like single-line getters or JNI calls. It was actually useless as a performance tool of any kind, which is why the recommendation for years has been to ignore the numbers it produced. It's great at answering questions about what a given function ends up doing, but that's it.

If you want low-overhead timelines with duration numbers that actually have meaning that's the job of systrace ( https://developer.android.com/studio/command-line/systrace.h... ).

The new profiler is much nicer. I'm a fan of the network monitor, it has a timeline of your requests, shows your JSON payload bodies, and previews images. I was mainly using Facebook's Stetho bridge for this, if Studio adds a good Sqlite inspector I'll happily kill that dependency.

Is the emulator getting better?

Between the introduction of Instant Run and Genymotion going to a paid business model, I'd say the Emulator has improved exponentially. I tend to alternate between using the Emulator and using a device depending on what I'm working on.

Yes, I've found it to be much faster than it used to be and they've added a lot of settings to simulate different environments. They also recently added quick boot in the preview (https://developer.android.com/studio/preview/emulator.html) to improve the boot times.

no. but you should be using 1) virtualbox running android x86 ans 2) real devices for final arm testing

> virtualbox running android x86

is it faster than emulator properly configured to use KVM or Haxm with x86 image?

yes. just open port 5555 and then connect via tcp on your dev box (which in my case, is another virtual box vm running ubuntu so i can wipe everything down every time a new version of android studio arrives --you DO NOT want to upgrade)

Thanks, I'll give it a shot next time I need the emulator.

I mostly use real devices.

I didn't know you could install Android on Virtualbox, thanks for the tip!

I found a fault when using a webview and rendering em's - it (as well as Chrome in debug mode for touch devices) didn't show the 8x scaling issue you get with a real device, which was annoying.

> separate APKs based on language resources

While I'm all for smaller applications, this seems backwards.

I never thought I'd consider Xcode to be fast and lean on resources.

Xcode was a godsend despite its flaw.

what's its flaw?

I wonder how JetBrains shared the license for their IDE with Android the license. As far as I know IDEA community edition is open-source, but I'm wondering if they license allows what Android did with it.

Alternatively, and more likely, Google has a bespoke licence for it. They’re cooperating enough with JetBrains on this that they’re likely to have some agreements in place anyhow

Studio is also open source.

Not everything, Studio uses parts of CLion.

It also seems like a good way to promote Kotlin, which could be JetBrains's cash cow.

How is Kotlin itself making that much money?

Likely the same way Java does, licensing. But programming languages have to be adopted by a lot of people before they become really valuable.

Such a huge update with lots of new features. I hope smoothness was improved.

I only use it for a webview app so I'm not that much affected but I'm sad that the flat UI with those grey icons that are in Jetbrains' IDEs are now in Android Studio too.

I'd just like to apt install android-sdk and pass some .java file to a compiler, just like with any other language... In the past you could still just grab the sdk without an entire operating system's worth of GUIs, but they've removed that download option now. I'm down to using my own local copy whenever I use a different computer, together with a few shell scripts that I wrote to do the compiling for me, but that won't last forever with new sdk versions.

You can still download the tools from here https://developer.android.com/studio/index.html#downloads - see the section named 'Get just the command line tools'.

So glad the Android Monitor tool is finally replaced. Recently had to do some profiling, and the whole experience was really bad.

I hope this fixes the emulator on linux. I tried everything I could to get the emulator working, but there were numerous issues.

Is Android Studio today written mostly in java ? Kotlin ?

Are some portions written in native (c?) code ?

I'm glad to see Kotlin making its proper debut. Android has been crying out for something a little more expressive and less verbose than Java, and Kotlin fits the bill perfectly.

Kotlin is super nice. As a former C# dev who went into Android, I was really dissatisfied with Java, and Kotlin was my rescue. I had to write some C# recently, and I have to admit Kotlin does feel nicer. (Admittedly it is still lacking some good stuff in comparison, eg. _yield return_).

>Admittedly it is still lacking some good stuff in comparison, eg. _yield return_

Is that similar to Kotlin's buildSequence/yield/... implemented with coroutines? https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.coroutin...

It would seem so, but coroutines are still "experimental". I do hope it will catch up.

I wouldn't say Kotlin feels nicer in my opinion, they are both very expressive languages these days.

What I like about them both is that you can very often intuit how something is likely to work.

Kotlin + Anko makes Android development much less painful indeed.

What a time to be alive! :D

Here comes another exciting 3 days of fixing random crashes with our medium product build that builds fine on the command line.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact