
Android Studio 3.0 Release Notes - satysin
https://developer.android.com/studio/releases/index.html
======
foobaw
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.

~~~
jreck
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.

~~~
esrauch
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.

~~~
tauntz
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.

~~~
IA21
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.

------
singularity2001
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 .....

~~~
singularity2001
Session 'app': Error Launching activity

not much has changed :(

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

~~~
singularity2001
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)

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

~~~
pjmlp
I always wonder how they actually test it.

Last RC did not even update on Macs.

------
maxpert
Kotlin to rescue! Shameless plug [https://hackernoon.com/in-pursuit-of-better-
jvm-futures-kotl...](https://hackernoon.com/in-pursuit-of-better-jvm-futures-
kotlin-coroutines-281a79211b09) 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

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

~~~
gcb0
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.

~~~
PureSin
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](https://developer.android.com/studio/index.html)

disclosure: I work on the Android Studio team.

~~~
Griffinsauce
Egg, meet face.

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

~~~
jorgemf
JetBrains, not Google

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

~~~
jorgemf
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.

~~~
biafra
But it still helps that they endorse it.

------
morsch
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/](http://scala-on-
android.taig.io/editor/android-studio/)

------
anad7
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.

~~~
biafra
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.

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

~~~
on_and_off
>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.

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

~~~
on_and_off
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.

~~~
mikestew
_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.

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

~~~
eatfish
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!

~~~
kllrnohj
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 :)

~~~
eatfish
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.

~~~
kllrnohj
> 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...](https://developer.android.com/studio/command-
line/systrace.html) ).

------
pier25
Is the emulator getting better?

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

~~~
kasabali
> virtualbox running android x86

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

~~~
gcb0
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)

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

------
kasabali
> separate APKs based on language resources

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

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

~~~
soulchild37
Xcode was a godsend despite its flaw.

~~~
__alias
what's its flaw?

------
drinchev
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.

~~~
pdpi
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

~~~
dcow
Studio is also open source.

~~~
pjmlp
Not everything, Studio uses parts of CLion.

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

------
conradfr
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.

------
lucb1e
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.

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

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

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

------
yazr
Is Android Studio today written mostly in java ? Kotlin ?

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

------
grabcocque
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.

~~~
V-2
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_).

~~~
realharo
_> 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...](https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.coroutines.experimental/build-
sequence.html)

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

------
alexfi
What a time to be alive! :D

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

