Google Launches Android Studio 3.5 With Improved Memory Settings, Build Speed, and Apply Changes

Google today launched Android Studio 3.5, the latest version of its integrated development environment (IDE), with a specific focus on "product quality." From a report: This release is the last one under Project Marble, a fancy name for an initiative Google announced late last year to improve Android Studio. For eight months, the team focused "on making the fundamental features and flows of Android Studio & Emulator rock-solid." All the improvements were either to system health, feature polish, or bug fixes. To improve system health, Google created a new set of infrastructure and internal dashboards to better detect performance problems. The team ultimately fixed over 600 bugs, 50 memory leaks, and 20 IDE hangs, and improved XML & Kotlin typing latency. For the Android Emulator, the team decreased the CPU and memory impact. The team also took a look at app deployment flow to a device, replacing Instant Run with Apply Changes. The new system no longer modifies an APK during your build. Instead, it uses runtime instrumentation to redefine classes on the fly.

Breaks Apply Changes for Pre-Oreo OSs

[Carcass666]

We have an internal application that we maintain that runs on tablets still on Nougat (Oreo is still getting tested). The new Apply Code Changes functionality now only works with Oreo and up. Kind of blows...

Emulator work was huge for CI

[MagicMike]

For the most part now, the emulators in continuous integration environments Just Work, whereas they were the fiddliest beasts prior.

I personally thought the IDE enhancements were boring (likely because the bugs just didn't affect me personally) but as an infrastructure-oriented person the randomness of the emulators working or not working when headless was maddening before the fixed them during this project

They don't care

[phantomfive]

The team ultimately fixed over 600 bugs, 50 memory leaks, and 20 IDE hangs

I would be embarrassed to admit that. It shows a deep lack of caring about their product for a long time.

Re:

[MagicMike]

I don't know what classification the "bugs" were (enhancements? P5 bugs? critical?), or how their issue open / close ratio or issue vs feature ratios look so it appears inferring their level of care and implying they should feel shame is a bit much.

Honestly, the 3.x series in general hasn't been bad to develop on. Compared to the number of features and size of the userbase I'm surprised they don't close more than that.

Look at other large projects and their issue stats when they do quality pushes - there is

Re: They don't care

[phantomfive]

Visual Studio code is an example of a crap product from Microsoft (I say that as I take a break at this moment from using it). At one point it was using 13% of the CPU power just to blink the cursor. A company that doesn't prioritize bugs doesn't prioritize security: if the bug list is growing continually, you know security bugs are right around the corner.

Re:

[MagicMike]

Too funny - half the developers choose to use a tool despite the availability of free alternatives but it's crappy: https://insights.stackoverflow... [stackoverflow.com]

But, okay. I find when I have all the bells and whistles on for any product it's slow, but I always figured I asked for it.

It's possible to turn nearly everything off on VSCode (Android Studio too) and have them work just fine.

If not, you can always go back to vim or emacs right? But then what to grumble about!

Re:

[phantomfive]

I find when I have all the bells and whistles on for any product it's slow,

Are you talking about bells and whistles like having a cursor that blinks?

Re:

[MagicMike]

Conflating what you see - blinking the cursor - with all the activities an IDE does shows a sad lack of imagination.

Typically when I'm in Code it's listening intently for filesystem events, might be re-running tests with coverage in the background, is pinging a couple different sites for status on issues, PRs and CI pipelines etc, possibly checking git, and on and on.

So I'm going to take this as willfull ignorance and a desire to be peeved, and hope you that works for you - in my way-too-long experience I g

Re: They don't care

[phantomfive]

No lol. It was the blinking cursor. If you had used a search engine you would have verified this. And I'll bet your code is filled with bugs for the same reason: you don't test to make sure it is correct.

Re:

[MagicMike]

Like I was going to do research on behalf of some grumpy person on the internet

Enjoy waiting for the golden age of software - it'll come as soon as we get to 100% coverage!

Re: They don't care

[phantomfive]

I don't ask for 100% coverage. I just ask that if you write or modify code that you test it all at least once.

Was I the only one...

[Izhido]

... that read that as âoefundamental flawsâ ?

Bugs in the Studio part or IntelliJ code?

[iampiti]

Since Android Studio is based on IntelliJ I wonder if the bugs fixed were in the code exclusive to Android Studio or in the base IntelliJ code. If it's the latter I guess the changes will be marged in the main IntelliJ product.
Just a rant/curious.

Good for audiophiles

[guacamole]

It is great that the Android Studio continues supporting the 3.5mm headphone jack.

I'll believe it when I see it

[EirikFinlay]

So far the build speed of android studio has been painfully slow... so slow that or is beaten 10 to 0 by pretty much anything else. It can take whole minutes to compile a simple barebone app while even a large visual studio project only takes a few second for a full rebuild. I'm not sure what the problem is with android studio, but right now it is so slow that it is almost painful. In my 30 years of career in software development I never encountered something this slow on a f***ing Core i7 with 8GB of RAM a