Google Launches Android Studio 2.0 | Hacker News Reader

Google Launches Android Studio 2.0

techcrunch.com

532 pointsGarbage168 comments

"Instant Run lets developers build and deploy their apps once (both to the emulator or to a physical device) and then as they change their code and deploy it, it’ll only take a second or two before they can see those changes in the running app. This feature will work for all apps that target Ice Cream Sandwich and later. Cuthbertson politely refused to tell us how exactly Instant Run works, but promised that Google will detail the technology behind this feature in the future."

This could be awesome, if it works as advertised.

I guess it works similarly to edit and continue in visual studio.

If done directly on devices too, I'm assuming runtime hacks similar to Xposed that swap code out right away.

Yes, it sounds more like monkey patching the apk than simply changing the running code. Hard to say without more details. /starts download

Instant Run would be awesome on iOS...

React Native supports it on both platforms. Also live reload. :)

Same with NativeScript.

Interesting. Have you used NativeScript for a commercial product? It's the first time I hear about it and I'm curious to hear an opinion about it.

I've been playing around with it, but not for a full project. It's very interesting - unlike React Native the JS has full access to all native APIs, so if you want to call one no-one has written a wrapper for yet you just can.

I've actually ended up writing a lot of platform specific code as I found the cross-platform stuff to be kind of janky. But it basically lets me write an iOS app, using iOS APIs (and even iOS sample code, if I apply myself)... in JavaScript. It's not bad at all.

> unlike React Native the JS has full access to all native APIs, so if you want to call one no-one has written a wrapper for yet you just can.

Yup I think I'll stay as far away from that as possible! Sounds like a recipe for a 10 hour debugging binge. I think managed APIs are pretty essential when doing interop.

Depends what you're trying to do. For instance, I was playing around with notifications in iOS. They have the ability for you to download data in the background before a notification is opened, which is a tremendously useful thing to be able to do. Last I checked the multi-platform frameworks don't allow you to do it - so being able to use NativeScript's cross-platform stuff then augment it as you desire is a pretty great thing.

Haven't used it for a commercial project, only toying around at night. But the company I work for does use another of Telerik's products, Kendo UI.

Well it's easy when you don't have to monkey patch assembly jumps.

There is a limited form of it available as an Xcode plugin.

- https://github.com/johnno1962/injectionforxcode

I dev Droid and iOS natively, and am playing with instant run now. iOS simulator still faster than Instant Run on a real sized project. Instant Run just helps to bring more parity, but is still not there yet.

I imagine they only change the modified activities. I guess they can't do that for games...

Yup, modified activities but games should be able to take advantage of this as well. In the timestamp below, it shows the presenter making the chess pieces larger and smaller. It is available on the canary build beginning today. Give it a try?

https://www.youtube.com/watch?feature=player_detailpage&v=YY... (lifestream timestamp is probably inaccurate)

It starts 26 minutes in, so people should look at the start time and just forward 26 minutes.

It's the second speaker, a woman right after the man that comes first.

Just tested. It doesn't replace the activities, it replaces parts of the compiled code (classes' dex?) with new versions.

It works well most of the time. Sometimes it can cause some nasty crashes. I guess it's expected since you can't just replace some object instances and expect it to work.

The settings does have an option to also restart the current activity when it does the hot swapping. I guess it's to account for those cases when hot swapping doesn't work as expected.

It crashes? That's pretty bad. VS Edit&Continue and Eclipse JDT, which also do something similar, warn you when a change can't be applied live (or would cause a crash resuming on old state).

I've generally found with this feature in various IDEs that it's good for changing a constant in some drawing code but not really much else, and then it just turns into frustration as you get constant popups reminding you it won't apply some change live. I think the problem is that in the timeframe companies like Google and Microsoft allocate for such a feature, it's extremely difficult to produce something that works 99% of the time. If we could get there (and improve step backwards functionality, as well) we would probably just abandon the divide between programming and debugging mode in IDEs and always have an updated copy running (or mostly, paused) alongside ready to context-switch into.

It's definitely possible. JRebel for Android [1] has been available for quite some time now with none of the limitations on what kind of changes are supported. Will they get it stable? Time will tell.

[1] https://zeroturnaround.com/software/jrebel-for-android/

You can do this with CoronaSDK based apps already (on all platforms even)

I just tried it, it works pretty well. You can also ask it to relaunch the activity.

For some reason, it doesn't work with my radio button text, it doesn't update it, but it works with labels and button texts. Well, maybe it's not stable yet, but it's awesome, and I'm happy that it's there.

I've had hit and miss results so far, sometimes it's great and then a bunch of times it ends up launching the app twice. Perhaps I'm either doing something wrong or I'm not hitting the right use when this works flawlessly. So far, however, hit and miss with little clear reason.

My hypothesis is that launching the app twice actually means it's crashing the app.

When the app is running, and you do an instant run from Android Studio, it will try doing the hot swap. The app crashes and immediately relaunches (and it's the same build). All the while Android Studio is monitoring the app task and waiting for the hot swap to take place. It keeps checking, times out after a few seconds (realizing it didn't update successfully), and then it deploys and launches the new APK, as a last resort.

My point is to be careful when testing if you're getting the double launches, because the first time it is launched, it's still the old APK.

It does not seem to be working for me. It does not reflect logic changes and I thought it was only for UI,however that also had no effect.Am I doing something wrong?

I think they have to compete with how React Native handles it, to make sure the developer experience developing Native Android apps is at least at par with those developing using React native, Ionic etc.

Here's the link to the Download page: http://tools.android.com/download/studio/builds/2-0-preview

It's not in the stable channel yet, so I assume it's not really released for the broad public yet?

This is why TechCrunch isn't great. Here are the actual details:

http://android-developers.blogspot.com/2015/11/android-studi...

It's in Canary right now.

Good catch. Here's what Google says: "Since this initial release is a preview, you may want to download and run an additional copy of Android Studio in parallel with your current version."

it is a canary build

right now I can't get the android build plugin 2 alpha (needed for instant run). It will probably be released in a few moments

Do you know what improvements this build has for android NDK? Last time I checked the Gradle build plugin for NDK was still experimental and there were a lot of hacks to build and to package native libs into apk file.

They've been constantly improving it. It'll depend on your build needs, but editing is much better already:

http://tools.android.com/tech-docs/android-ndk-preview

It's not the same as Eclipse, in that you could just setup a ndk build script to run when you saved a file... it's supposed to be much better (since you're supposed to edit C files and have full autocompletion and all).

The only awkward part was building the .so files - as long as you could do that (and you could always do that separately with your make files) you were good to go. Building the final apk is fine as long as you have the jni files in the right locations.

Sorry for off topic but why does every news site mobile layout wants me to click read more/continue reading? Now techcrunch too. I tried to Google the question but didn't get an answer.. Who and why invented this trend?

Is it to measure engagement? Surely there are better ways.. Most of the sites don't lazy load the hidden content, so there's no bandwidth benefit either...

Also interested to know. Surely just seeing every so often where the content is scrolled too is much better than this?!

Probably related to ad revenue across the various sites.

This is just a hypothesis, but maybe for viewability for ads? There's a big controversy among advertisers/publishers over the difference between "was my ad shown" and "was my ad seen." Clicking Read More at least says you're going to look a little down the page. Some evidence for it is that right below the "Read More" button, there's usually an annoying little ad square.

Could be a performance/turnover-rate thing. If they only have to send a small bite of the article in the beginning, it means a smaller response body, which means the page will load faster. You are less likely to close the page in frustration as it continues to load.

I don't think this is the reason. The amount of text that is contained in the article is usually smaller than the shit ton of superfluous JS and images they're sending. If they're looking to optimize page load, there are lower-hanging fruits.

Maybe you could just get bored within the article and they want to show you more content before you leave the page. if you actually want to finish the article a simple button press isn't trememndous. just keep your interest and show you alternatives early.

Because it breaks most mobilizers/"reading mode" browser plugins which means they can show you more ads.

On a lot of pages it actually doesn't.

Hmm... I have uMatrix installed and it just loads the whole page.

CNN has it too, it's annoying.

Can someone explain this to me?

Windows version: x64

Mac OSX version: x64

Linux version: x86

Why? Why do companies not release 64-bit versions of their programs for Linux? This seems to happen all the time, and it utterly baffles me.

Most probably the developers working on Linux port run 32 bit Linux themselves because of compatibility with some closed-source programs. ;)

I have no idea about the real reason, it's just a wild guess.

Windows server is x64 only. Might as well knock that support off the list at the same time. OSX is 64 only right?

x86 only linux just halved your compile and packaging times. Only answer I can assume.

Official announcement on the Android Dev blog: http://android-developers.blogspot.com/2015/11/android-studi...

https://duckduckgo.com/?q="amazingly+stabled"

Did TC have the best rewritten press release? There doesn't seem to be any mention of 2.0 on http://developer.android.com/tools/studio/index.html for example.

It won't be there for a while. It should be on http://tools.android.com/recent soon (it should have been already, but I guess they were waiting for the conference to start before putting it there).

Is there any reason to hold out for a non Java/JVM Android development experience? I remember rumors of Dart or Python, but those seem to have died.

Java is the language of the platform for the foreseeable future. You might want to check out something like Kotlin (great language which compiles to java bytecode) but IMO there is little reason to invest in Dart for Android right now.

It is heralded by the Dart team, entirely independently from the Android team. AFAIK, they are just shopping for a problem to solve with Dart now that they are not going to be able to ship their VM with Chrome.

You might be referring to Flutter, which is a project of Chrome, started independently from Dart, and who's purpose is to make the core of Chrome better for app development, not find a purpose for Dart.

Flutter started with JS as the scripting language. The Dart team is certainly lending a lot of support to Flutter, because of the promise of a compelling mobile story for Dart.

I have strong suspicion that Google will support Go in the future: - Go 1.5 introduced support for mobile development (and Android in 1.4): https://blog.golang.org/go1.5 - If Android can become less bound to Java, I see Go becoming the go-to language for Android development.

Then they will need to change their official statement that only Java matters, as communicated at Google IO 2014 Android Fireside.

You should check out http://flutter.io/ which is a Dart environment that works on Android and iOS. It's probably closer to web development (without a document or CSS), than traditional Android development.

Does anyone know how this compares to the speed of running apps under something like genymotion? It basically creates an android device in virtualbox. The speed blew me away compared to the old android virtual devices. Granted, I hadn't messed with android development for a couple of years before that, so it's possible everything is that much faster now..

Yes would love to know how this compares to Genymotion...

Instant Run is different from Genymotion. With both, you should be able to get < 1s compile + deploy times if you're making a change supported by Instant Run. On my 3 years old Linux laptop and a Nexus 4, Instant Run compiles and deploys within 2 seconds :)

Instant run sounds a bit like Buck's exopackage:

https://buckbuild.com/article/exopackage.html

Although the example they show is editing a resource, so it could be fast-pathing resource-only edits (buck does that too).

More docs here:

https://sites.google.com/a/android.com/tools/tech-docs/insta...

Offtopic: is the experience as good on Windows and Linux as on OSX? I'm planning on selling the MBP (too expensive to keep hardware up-to-date in third-world countries).

Works fine on Linux. The IDE is Java based and it packages all the necessary tools with it so it should work fine anywhere.

Eclipse is Java based and packages all the necessary tools with it but it is extremely debatable whether that means it "works fine" anywhere...

But to address the grandparent post a bit more directly, in my experience Android Studio runs great under both Windows and Linux, I've used it frequently on both with no complaints.

The instant run feature this new canary build has will be welcome since the deploy->run cycle has always been just slow enough to feel like a bottleneck to me, though I never faulted Android Studio for this.

What has this to do with Eclipse? Android studio is IntelliJ based.

Theyre both written in Java

Which means nothing.

Is it really so hard to understand? I was responding to a specific comment which was:

"Works fine on Linux. The IDE is Java based and it packages all the necessary tools with it so it should work fine anywhere."

Eclipse fits all those criteria (IDE is Java based and it packages all the necessary tools with it). But I would argue Eclipse doesn't "work fine" anywhere, it is a bloated, slow piece of crap (equally, everywhere), thus those criteria are not really that useful in determining if something "works fine" somewhere.

As a ten year (now-cured) Java/J2EE developer, I whole-heartedly agree with you that Eclipse is a bloated, slow piece of crap.

IntelliJ is much better, very quick and responsive. It's actually a great demonstration of how Java apps don't NEED to be slow PsOS. I'm an iOS guy and didn't know about Android Studio, and the prospect of going back to Eclipse has kept me from even thinking about Android dev. Now I might well give it another try.

I've used Android studio on both Linux and OSX, and there's no difference. Both work great.

Same here. Only differences I've hit are fonts and most of the time I can't get adb to work on OSX.

I've never gotten the Emulator to work in Windows (8.1), and from what I gather after some googling I did at the time it is at best challenging to do. I'm hoping the talk of new emulators as part of the instant run stuff will have Windows sorted out and not be a 3rd (or worse) class citizen again.

Currently the emulator is faster on Linux (because it can take advantage of KVM), but the new version should improve performance on Windows AFAIK

The Windows emulator used to take advantage of HAXM.

I had issues with fonts in Android Studio & IntelliJ on Linux, but other than that it is totally fine. I know there are font work arounds, I've messed around with it a few times and sometimes gotten it working and sometimes not.

In IntelliJ 15 there's a new setting Settings > Appearance and Behavior > Appearance > Antialiasing > Editor. Set that to "Greyscale". Fixed all font issues on 2 different Linux boxes (Fedora 20 and Debian unstable). I use Consolas.

If you have 8GB or more of RAM you should be fine on either OS. 4GB is doable if you refrain from opening too many browser tabs.

it uses swing so linux font rendering is terrible. You can use openjdk font fix patches but that is very slow

Font is fine for me. Only sometimes I had trouble in the last years. Stackoverflow is your friend then.

I use it on all 3 platforms, works great on all of them.

Is there any chance of Java 8 support landing anytime soon?

Google is probably very wary of going more into Oracle territory.

Given Android's adoption at this point, if I were Google's management, I'd adopt another JVM language. Sort of Objective-C -> Swift. Kotlin would probably the safest bet from an "easy adoption" point of view.

Given they don't have a JVM, I don't think anything makes adopting a JVM language easier.

I think that's pretty disingenuous. Just because they don't call it Java doesn't mean they don't have a JVM.

Not implementing the JVM spec means it's not a JVM. It's that simple.

OK but you're straying into pedantry. They have their own VM which runs bytecode generated by a translation layer. The only language supported by that translation layer is JVM bytecode. Therefore, they effectively have an implementation of the JVM.

Actually ART runs DEX bytecode not JVM bytecode so I'd argue it's not a JVM at all. By your definition anything that can translate Java to an intermediate representation is a JVM. Does that make LLVM a JVM?

https://llvm.org/svn/llvm-project/java/trunk/docs/java-front...

No, but ART's sole purpose is to run JVM translated programs. If you had another fm that run Java and other languages, you could argue that it is A JVM, but it is also a fm for what ever the language it runs.

I am guessing Oracle's lawyers will argue that is indeed the case. Let's hope they do not prevail

They lost that argument against Google already.

> OK but you're straying into pedantry.

You are stripping words of their meaning. There is a precise definition of what JVM means. ART isn't close to that and doesn't try to do that. There's nothing wrong with that, just don't call it a JVM.

You can translate Java into JavaScript and run it on a JavaScript VM. This doesn't make that JavaScript VM a JVM.

Pointing out that a language isn't Java simply because it has curly braces isn't straying into pedantry. Pointing out that something isn't ice simply because it is solid isn't straying into pedantry.

They're not stripping anything of it's meaning; they're taking things to their logical conclusion. And there's really no way that you can claim the language used for Android development is not Java.

It's clear you don't understand how the ART VM works so why not research it instead of trying to argue how you think it works.

I know how it works. Claiming that someone who disagrees with you must not know how something works doesn't exactly prove your point.

> And there's really no way that you can claim the language used for Android development is not Java.

Even if the language used for Android development is were Java that wouldn't make ART a JVM. JVM is a VM specification that is not tied to the source but the byte code. In several cases (eg. method lookup) there a significant differences between Java and JVM semantics.

The language used for Android development is not Java. Again, there is a precise definition of what Java means (the language specification) and a test to verify what you have is Java (the TCK). ART/Android does not pass that test (it's not even close) and has no intention of doing so. For example Java semantics allow on the fly code generation. AFAIK ART/Android does not support this.

I would argue who is being pedantic. They have a Java SDK so of course they're going to have a JVM bytecode->DEX bytecode translator, but that doesn't mean their VM is even remotely close to a JVM as they don't even share the same architecture.

They're using the Java language. Therefore, something which interprets bytecode coming from it is a java virtual machine. It's that simple.

You couldn't be more wrong. The ART VM processes DEX bytecode and it is not compatible with JVM bytecode. They also use different architectures.

Are you trying to say that the Java language isn't being used to write Android apps?

No, I'm saying the relevance of Java ends at the source level. When the app is converted to DEX bytecode and then compiled to native code there is no dependency on the language or JVM as you seem to think.

There clearly is, otherwise Google would have been able to update to Java 8 on Android by now.

No, the reason Google isn't going to update to Java 8 is due to the litigation from Oracle. Google will likely transition to a new language so why invest time and money upgrading to a language they're going to abandon soon.

It's not being disingenuous: by definition, a JVM has to execute Java bytecode, Android's toolchain merely uses Java bytecode as an intermediate representation. Dalvik VM =/= JVM, insisting it is because the source code was written in Java and/or transitioned through Java bytecode is being disingenuous. It would aslo imply Linux a JVM because GCJ[1] can compile Java bytecode to (Linux) executables.

1. https://gcc.gnu.org/java/

I'd say that it simply has to execute something coming from Java code. Which both Dalvik and ART do.

I think claiming that Dalvik VM and JVM are so different when they both run stuff coming from Java is just trying to split hairs.

No it doesn't. As long as the language compiles to DEX bytecode the ART compiler and runtime can execute it. The JVM and ART VM are very different and don't even use similar architectures. I should also remind you that Oracle tried to sue Google in regards to VM IP and lost spectacularly so your claim that the old Dalvik VM and JVM are similar and any differences are just trying to split hairs is erroneous.

I suggest you look into the ART runtime. It's not a JVM. For starters it's register based and compiles DEX bytecode into native code.

Kotlin already runs on android as well as groovy

JVM- and Android-targeted Kotlin were built in simultaneously, whereas Android-targeted Groovy was added on last year as an afterthought, so the QA aspects of each will likely be very different. Also, the full-time developer working on Groovy's Android codebase was retrenched last year, whereas Jetbrains is still supporting Kotlin's Android codebase.

Kotlin seems to be the way that this is moving, especially with Kotlin being added to IntelliJ IDEA 15 [1]. I would imagine that Kotlin support would be built into Android Studio soon.

[1] - https://blog.jetbrains.com/idea/2015/11/intellij-idea-15-rel...

If they get serious about Flutter (http://flutter.io/) they have a non JVM path forward.

Java is not exactly Oracle's territory.

Swift and Objective-C are Apple's territory if Java is Oracle's territory. Besides they are more like no-languages than programming languages. There is a huge number of Java programmers out there compared to Kotlin or some other "it is so cool" language.

No, the safest bet is Eclipse Xtend - http://www.eclipse.org/xtend/ - which compiles to Java.

I don't think so. In order for that to happen, Google would need to support new bytecodes in their JVM (Dalvik? I forget), which would be a backwards-incompatible change. So unfortunately I don't expect to see Java 8 in Android for quite a while.

Dalvik has been replaced by ART (the Android Run Time) in 5.0 Lollipop. Dalvik was the JIT compiler in 4.4 and below, and with 5.0+, ART is an ahead-of-time compiler.

There's still lots of Dalvik based devices in use.

http://developer.android.com/about/dashboards/index.html

They still could let us choose, no?

You already have to choose between Java 7 and target only 4.4 onwards devices or use Java 6 to be able to target older devices.

They could have released Marshmallow with Java 8 support, so that in the same way one could choose to target 6.0 devices and newer or not.

Give Kotlin a try. I have great experiences with the language on both mobile and server development. Don't miss Java 8 a bit when I do server development in Kotlin.

As appealing as Kotlin can be, many of us are only allowed to use platform languages on customer projects.

Hence why Google's silence on the language support is so irritating.

I could do without another Android Studio release, if they provided an open roadmap for Android for whatever language they think on supporting going forward. Instead of pure silence.

As it is, we will be using Java 10 on the desktop, server and IoT devices, when they eventually remember to let us know of a new platform language.

Considering Google's friendly relationship with Jetbrains (Android Studio) I'm more likely to believe that they will just make Kotlin an official language.

Yes. There are loads of commits in the Jack and ART repositories of AOSP relating to Java 8 features like lambdas, method references, and default methods.

I'd expect them to come with the next release of Android (since they require new VM bytecode instructions), with a possible official back-port tool similar to Retrolambda.

I wonder if these capabilities will come to the few of us who still prefer the command line or if we'll be forced to upgrade.

Instant Run only works from within Android Studio.

We still support command line builds (and will continue to do so). However, as I understand it, there wasn't an easy way for us to deploy an incremental build from the command line, as this takes advantage of an integration with the IDE.

Of course, both Android Studio and the build system are open source, so you're free to take a look at how it's done.

Will it be supported in the IJ Android plugin, say within IJ CE/Ultimate?

I am torn between this and CodeWorks for Android by NVIDIA. I realize CodeWorks is more for game devs, and carries a lot of GPU support, but it is a one-click install and ties nicely into MS Visual Studio.

Does the emulator support high density displays yet? It's been like 4 years.

Video of announcement during Android Dev Summit:

https://www.youtube.com/watch?v=YYin_N6xXxQ&feature=youtu.be

Skip to ~1:00:00

> One area Google has recently focused on is app indexing, which brings content from apps into its search engine

Hmm. I wonder if the search engine is going to phone home anything it finds interesting in your local files.

I have to admit, I vastly prefer web development right now as waiting at least 30 seconds for your native Android app to compile and run on a device really sucks the fun out of it for me compared to just refreshing a browser. Hopefully the live reload feature improves this!

Exactly my thoughts. I've been working with native Android apps for 2 years now and I still miss the Web's awesome feedback cycle.

It's a preview. 1.5 just comes out a short while ago.

The best part they solved is improved compilation speed!

By my experience (based on the project I'm working on) regular build speed hasn't changed at all. Obviously I'm not saying there's no improvement, only that apparently it's not universal.

Google has the resource to build their own text editor -- so why don't they do it? It seems displeasing to have to work with 3rd party software in order to develop an Android app. And this is not to say IntelliJ is a bad choice, but it would seem that they could rid away with any extraneous portions of the editor. It could also be optimized for Android development, unless that's what this "Android Studio" is.

Because an IDE isn't just a text editor. It takes a nontrivial amount of time and people to get a good IDE running. If you consider that a lot of this time is spent on features that have already been implemented somewhere else, it makes sense to leverage an existing project and then, on top of it, work on hard features that really have an impact on Android development - as is the case with the new Instant Run, for example.

> Google has the resource to build their own text editor -- so why don't they do it?

Because they realize that reinventing the wheel for the sake of being 100% google-made is a pointless endeavor.

> It seems displeasing to have to work with 3rd party software in order to develop an Android app.

People work with third party apps all the time in the development of applications whether they are mobile, web or something else entirely.

>And this is not to say IntelliJ is a bad choice, but it would seem that they could rid away with any extraneous portions of the editor. It could also be optimized for Android development, unless that's what this "Android Studio" is.

How is it not optimized for android development. What, in your opinion would be an optimized version of the current IDE?

Modern mobile development does not rely on text editors but IDEs and there is an huge difference between the twos.

Google has the resources to build a text editor, but an IDE ? that would take years and would still be unable to compete with XCode / Visual Studio.

So Google chose to take a great IDE, shower it in money and use it as the basis for their own tool.

That way, they automatically get everything Intellij already offers for Java : syntax colouring, smart refactoring, code flow analysis and so on and they can just focus on adapting the existing tools for Android and adding new ones (Lint, SysTrace, ... )

> It could also be optimized for Android development, unless that's what this "Android Studio" is.

That's pretty much what it is, I don't see how you could optimise it more for Android development.

> Google has the resource to build their own text editor -- so why don't they do it?

Because they don't need their own text editor, they need an IDE; and just because they may have the resources to build their own IDE doesn't mean that that's the most cost effective mechanism available: "adopting" an existing IDE and sponsoring an Android-specialized spin, which is what they did with Android Studio, is a lot faster payoff and a lot more cost effective than starting from ground zero.

(Now, if they had a revolutionary idea for how to do a development environment differently, it would make sense to build it out in house. But that's a different issue than getting high-quality but basically conventional tooling available for Android development.)

Does Microsoft really not care when competitors release their own IDEs called * Studio?

Does Microsoft release any Studio besides Visual Studio? If they don't, why should they?

Yes. There is at least Windows App Studio (http://appstudio.windows.com) that I know of offhand and Microsoft Robotics Developer Studio (http://www.microsoft.com/robotics) that I found in 5 seconds of searching.

It's perfectly reasonable to think that if they ever released an Android IDE, either for the mobile OS or for actual androids, it might be called Android Studio.

They wouldn't call it that because Android is a Google trademark. "Visual Studio for Android" would be ok.

Neither is really any more or less OK than the other. Whether or not either is OK is a matter for the USPTO, courts, lawyers, and private agreements to determine.

Android Studio as a development tool for building anthropomorphic robots might be OK whether Google liked it or not ;-)

Well, you're right, but Google explicitly has said that "X for Android" is ok because they allow it for apps on Google Play (whereas naming your app "Android X" is forbidden and can get you banned).

Fair enough (note that "Android Studio" would presumably not be an "App" so much as a desktop IDE).

Actually, no it wouldn't as they would be sued for trademark infringement by Google.

Pretty sure it doesn't matter, considering "Studio" is a common term...

Yes, like Candy.

Like Saga, you mean? I don't recall any cases around the word Candy, but The Banner Saga got hit.

Yeah, King trademarked "Candy" and had an app taken down from the App Store http://www.polygon.com/2014/1/21/5332560/what-kings-candy-tr...

Good lord, did they trademark Crush as well?

So is "Word". I would be equally surprised if Google released word processing software called "Android Word".

If I created a word processor called "Mike's Word Processor" I'm pretty sure I'd be good.

This reminds me of the Microsoft vs MikeRowSoft case [1], where Microsoft took legal action against a high schooler for a domain that was phonetically similar to their company name.

[1]: https://en.wikipedia.org/wiki/Microsoft_vs._MikeRoweSoft

WordPerfect existed before MS Word

Which is clearly a different trademark despite the fact that they share one word that is key to describing the product's functionality. Might as well compare Burger King and Whataburger.

They might care but I doubt they have any legal right to the word "studio". Lots of software has Studio in the name, many of which were released before VS.

Do you have any examples of some that act as IDEs or similar? The ones I know of are all created by Microsoft.

Apple Records didn't have a problem with Apple Computer until Apple Computer started selling music.

Xamarin Studio, Monkey Studio, Atmel Studio, Aptana Studio, Zend Studio...

RStudio, Oracle Solaris Studio, Appcelerator Studio, etc etc.

3D Studio.

Do any of those actually predate Visual Studio (i.e. 1997)? (Not suggesting Microsoft owns the word "Studio" but you're not actually answering the question.)

When Microsoft starting referring to its developer suite as Visual Studio it was using Studio as a catchall for all the development tools it had branded as "Visual" (starting with "Visual Basic" in the early 90s).

I had never heard of any but the first and Microsoft and Xamarin are so tight I had assumed it was just Visual studio with Xamarin sprinkles on top.

Xamarin Studio is MonoDevelop (http://www.monodevelop.com/)

> Apple Records didn't have a problem with Apple Computer until Apple Computer started selling music.

Untrue!

> In 1978, Apple Corps, the Beatles-founded holding company and owner of their record label, Apple Records, filed a lawsuit against Apple Computer for trademark infringement. The suit was settled in 1981 with an undisclosed amount being paid to Apple Corps. This amount was estimated to be US$50–250 million, but was later revealed to be $80,000. As a condition of the settlement, Apple Computer agreed not to enter the music business, and Apple Corps agreed not to enter the computer business.

from https://en.wikipedia.org/wiki/Apple_Corps_v_Apple_Computer

Yes, I know. If you look at their relationship after that suit and after iTunes launched, it's clear that it was only the latter that was a "problem".

> Then there's the observation that a lot of voters certainly seem to want the President to be a dictator

Sun Java Studio Creator (ca. 2004) is the earliest non-MS IDE with "Studio" as part of its name that I can think of.

That would be like naming your product "Magic Spreadsheet" and then suing everyone else who uses the word "Spreadsheet".

>Does Microsoft really not care when competitors release their own IDEs called * Studio?

I can't tell if this is a joke post. Microsoft would be spanked in a court of law if they even attempted such a silly move.

Reply on news.ycombinator.com