This could be awesome, if it works as advertised.
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.
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.
https://www.youtube.com/watch?feature=player_detailpage&v=YY... (lifestream timestamp is probably inaccurate)
It's the second speaker, a woman right after the man that comes first.
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.
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 not in the stable channel yet, so I assume it's not really released for the broad public yet?
It's in Canary right now.
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.
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
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...
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.
I have no idea about the real reason, it's just a wild guess.
x86 only linux just halved your compile and packaging times. Only answer I can assume.
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 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.
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.
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:
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.
"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.
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.
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.
 - https://blog.jetbrains.com/idea/2015/11/intellij-idea-15-rel...
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.
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.
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.
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.
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.
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.
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.
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.
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.
Skip to ~1:00:00
Hmm. I wonder if the search engine is going to phone home anything it finds interesting in your local files.
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?
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.)
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.
Apple Records didn't have a problem with Apple Computer until Apple Computer started selling music.
> 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.
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).
Sun Java Studio Creator (ca. 2004) is the earliest non-MS IDE with "Studio" as part of its name that I can think of.
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.
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.
Android Studio as a development tool for building anthropomorphic robots might be OK whether Google liked it or not ;-)